1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
\section1 Hardware Acceleration
When designing applications for embedded devices the choice often stands
between graphics effects and performance. On most devices, you cannot have
both simply because the hardware needed for such operations just is not
there. Still a growing number of devices use hardware dedicated to graphics
operations to improve performance.
Using graphics acceleration hardware is more power efficient than using the
CPU. The reason for this is that the CPU might require a clock speed that
is up to 20 times higher than the GPU, achieving the same results. E.g. a
typical hardware accelerated mobile graphics unit can rasterize one or two
bilinear texture fetches in one cycle, while a software implementation
takes easily more than 20 cycles. Graphics hardware generally have a much
lower clock speed and memory bandwidth and different level of acceleration
than desktop GPUs. One example is that many GPUs leave out transformation
and lighting from the graphics pipeline and only implements rasterization.
So the key to write good applications for devices is therefore to limit the
wow factor down to what the target hardware can handle, and to take
advantage of any graphics dedicated hardware. Qt provides several ways to
both render advanced effects on the screen and speed up your application
using hardware accelerated graphics.
\tableofcontents
\section2 Qt for Embedded Graphics pipeline
Qt uses QPainter for all graphics operations. By using the same API
regardless of platform, the code can be reused on different devices.
QPainter use different paint engines implemented in the QPaintEngine API to
do the actual painting.
The QPaintEngine API provides paint engines for each window system and
painting framework supported by Qt. In regards to Qt for Embedded, this
also includes implementations for OpenGL ES versions 1.1 and 2.0, as well
as OpenVG and DirectFB(Embedded Linux only).
By using one of these paint engines, you will be able to improve the
graphics performance of your Qt application. However, if the graphics
operations used are not supported, this might as well be a trap, slowing
down your application significantly. This all depends on what kind of
graphics operations that are supported by the target devices hardware
configuration.
\image platformHWAcc.png
The paint engine will direct all graphics operations supported by the
devices hardware to the GPU, and from there they are sent to the
framebuffer. Unsupported graphics operations falls back to the
QRasterPaintEngine and are handled by the CPU before sent to the
framebuffer. In the end, the operating system sends the paint updates off
to the screen/display. The fallback operation is quite expensive in regards
to memory consumption, and should be avoided.
\section2 Hardware configuration requirements
Before implementing any application using hardware acceleration, it is wise
to get an overview of what kind of hardware accelerated graphics operations
that are available for the target device.
\note On devices with no hardware acceleration, Qt will use
QRasterPaintEngine, which handles the acceleration using software. On
devices supporting OpenGL ES, OpenVG or DirectFB(not supported by Windows
CE), Qt will use the
respective paint engines to accelerate painting. However, hardware
configurations that only support a limited set of hardware acceleration
features, might slow the application graphics down rather than speeding it
up when using unsupported operations that must fall back to the raster
engine.
\section3 Different architectures
Based on the architecture used in a device we can make a recommendation on
which hardware acceleration techniques to use. There are mainly two
different architectures on embedded devices. These are devices with a
Unified Memory Architecture (UMA), and devices with dedicated graphics
memory. Generally, high-end devices will have dedicated graphics memory.
Low-end devices will just use system memory, sometimes reserving a memory
region and sometimes not.
In addition to this, we can categorize the devices into five types based on
the different graphics operations supported by their hardware.
\list 1
\o No support for graphics acceleration.
\o Support for blitter and alpha blending.
\o Support for path based 2D vector graphics.
\o Support for fixed function 3D graphics.
\o Support for programmable 3D graphics.
\endlist
Based on these characteristics the table below recommends which paint
engines to use with the different types of hardware configurations.
\section3 Recommended use of hardware acceleration based on hardware
\table
\header
\o Type
\o UMA
\o Non-UMA
\row
\o \bold {None}
\o Qt Raster Engine
\o Qt Raster Engine
\row
\o \bold {Blitter}
\o DirectFB
\o DirectFB
\row
\o \bold {2D Vector}
\o OpenVG
\o OpenVG
\row
\o \bold {Fixed 3D}
\o OpenGL (ES) 1.x
\o OpenGL (ES) 1.x
\row
\o \bold {Programmable 3D}
\o OpenGL (ES) 2.x
\o OpenGL (ES) 2.x
\endtable
\note Since the DirectFB API is quite primitive, the raster paint engine
handles most of the operations.
\note Blitter and Alpha blending is currently not supported on Windows CE.
|
