|
1 /**************************************************************************** |
|
2 ** |
|
3 ** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies). |
|
4 ** All rights reserved. |
|
5 ** Contact: Nokia Corporation (qt-info@nokia.com) |
|
6 ** |
|
7 ** This file is part of the documentation of the Qt Toolkit. |
|
8 ** |
|
9 ** $QT_BEGIN_LICENSE:LGPL$ |
|
10 ** No Commercial Usage |
|
11 ** This file contains pre-release code and may not be distributed. |
|
12 ** You may use this file in accordance with the terms and conditions |
|
13 ** contained in the Technology Preview License Agreement accompanying |
|
14 ** this package. |
|
15 ** |
|
16 ** GNU Lesser General Public License Usage |
|
17 ** Alternatively, this file may be used under the terms of the GNU Lesser |
|
18 ** General Public License version 2.1 as published by the Free Software |
|
19 ** Foundation and appearing in the file LICENSE.LGPL included in the |
|
20 ** packaging of this file. Please review the following information to |
|
21 ** ensure the GNU Lesser General Public License version 2.1 requirements |
|
22 ** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. |
|
23 ** |
|
24 ** In addition, as a special exception, Nokia gives you certain additional |
|
25 ** rights. These rights are described in the Nokia Qt LGPL Exception |
|
26 ** version 1.1, included in the file LGPL_EXCEPTION.txt in this package. |
|
27 ** |
|
28 ** If you have questions regarding the use of this file, please contact |
|
29 ** Nokia at qt-info@nokia.com. |
|
30 ** |
|
31 ** |
|
32 ** |
|
33 ** |
|
34 ** |
|
35 ** |
|
36 ** |
|
37 ** |
|
38 ** $QT_END_LICENSE$ |
|
39 ** |
|
40 ****************************************************************************/ |
|
41 |
|
42 /*! |
|
43 \page qt-embedded-accel.html |
|
44 |
|
45 \target add your graphics driver to Qt for Embedded Linux |
|
46 |
|
47 \title Adding an Accelerated Graphics Driver to Qt for Embedded Linux |
|
48 \ingroup qt-embedded-linux |
|
49 |
|
50 In \l{Qt for Embedded Linux}, painting is a pure software implementation |
|
51 normally performed in two steps. First, each window is rendered |
|
52 onto a QWSWindowSurface using QPaintEngine. Second, the server |
|
53 composes the surface images and copies the composition to the |
|
54 screen (see \l{Qt for Embedded Linux Architecture} for details). |
|
55 \l{Qt for Embedded Linux} uses QRasterPaintEngine (a raster-based implementation of |
|
56 QPaintEngine) to implement painting operations, and uses QScreen |
|
57 to implement window composition. |
|
58 |
|
59 It is possible to add an accelerated graphics driver to take |
|
60 advantage of available hardware resources. This is described in |
|
61 detail in the \l {Accelerated Graphics Driver Example} which uses |
|
62 the following approach: |
|
63 |
|
64 \tableofcontents |
|
65 |
|
66 \warning This feature is under development and is subject to |
|
67 change. |
|
68 |
|
69 \section1 Step 1: Create a Custom Screen |
|
70 |
|
71 Create a custom screen by deriving from the QScreen class. |
|
72 |
|
73 The \l {QScreen::}{connect()}, \l {QScreen::}{disconnect()}, \l |
|
74 {QScreen::}{initDevice()} and \l {QScreen::}{shutdownDevice()} |
|
75 functions are declared as pure virtual functions in QScreen and |
|
76 must be implemented. These functions are used to configure the |
|
77 hardware, or query its configuration. The \l |
|
78 {QScreen::}{connect()} and \l {QScreen::}{disconnect()} are called |
|
79 by both the server and client processes, while the \l |
|
80 {QScreen::}{initDevice()} and \l {QScreen::}{shutdownDevice()} |
|
81 functions are only called by the server process. |
|
82 |
|
83 You might want to accelerate the final copying to the screen by |
|
84 reimplementing the \l {QScreen::}{blit()} and \l |
|
85 {QScreen::}{solidFill()} functions. |
|
86 |
|
87 \section1 Step 2: Implement a Custom Raster Paint Engine |
|
88 |
|
89 Implement the painting operations by subclassing the |
|
90 QRasterPaintEngine class. |
|
91 |
|
92 To accelerate a graphics primitive, simply reimplement the |
|
93 corresponding function in your custom paint engine. If there is |
|
94 functionality you do not want to reimplement (such as certain |
|
95 pens, brushes, modes, etc.), you can just call the corresponding |
|
96 base class implementation. |
|
97 |
|
98 \section1 Step 3: Make the Paint Device Aware of Your Paint Engine |
|
99 |
|
100 To activate your paint engine you must create a subclass of the |
|
101 QCustomRasterPaintDevice class and reimplement its \l |
|
102 {QCustomRasterPaintDevice::}{paintEngine()} function. Let this |
|
103 function return a pointer to your paint engine. In addition, the |
|
104 QCustomRasterPaintDevice::memory() function must be reimplemented |
|
105 to return a pointer to the buffer where the painting should be |
|
106 done. |
|
107 |
|
108 \table |
|
109 \header \o Acceleration Without a Memory Buffer |
|
110 \row |
|
111 \o |
|
112 |
|
113 By default the QRasterPaintEngine draws into a memory buffer (this can |
|
114 be local memory, shared memory or graphics memory mapped into |
|
115 application memory). |
|
116 In some cases you might want to avoid using a memory buffer directly, |
|
117 e.g if you want to use an accelerated graphic controller to handle all |
|
118 the buffer manipulation. This can be implemented by reimplementing |
|
119 the QCustomRasterPaintDevice::memory() function to return 0 (meaning |
|
120 no buffer available). Then, whenever a color or image buffer normally |
|
121 would be written into paint engine buffer, the paint engine will call the |
|
122 QRasterPaintEngine::drawColorSpans() and |
|
123 QRasterPaintEngine::drawBufferSpan() functions instead. |
|
124 |
|
125 Note that the default implementations of these functions only |
|
126 calls qFatal() with an error message; reimplement the functions |
|
127 and let them do the appropriate communication with the accelerated |
|
128 graphics controller. |
|
129 |
|
130 \endtable |
|
131 |
|
132 \section1 Step 4: Make the Window Surface Aware of Your Paint Device |
|
133 |
|
134 Derive from the QWSWindowSurface class and reimplement its \l |
|
135 {QWSWindowSurface::}{paintDevice()} function. Make this function |
|
136 return a pointer to your custom raster paint device. |
|
137 |
|
138 \section1 Step 5: Enable Creation of an Instance of Your Window Surface |
|
139 |
|
140 Finally, reimplement QScreen's \l {QScreen::}{createSurface()} |
|
141 function and make this function able to create an instance of your |
|
142 QWSWindowSurface subclass. |
|
143 */ |