source: trunk/doc/src/platforms/emb-hardwareacceleration.qdocinc@ 564

Last change on this file since 564 was 561, checked in by Dmitry A. Kuminov, 15 years ago

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