source: trunk/doc/src/emb-accel.qdoc@ 432

Last change on this file since 432 was 2, checked in by Dmitry A. Kuminov, 16 years ago

Initially imported qt-all-opensource-src-4.5.1 from Trolltech.
File size: 6.2 KB
Line 
1/****************************************************************************
2**
3** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
4** Contact: Qt Software Information (qt-info@nokia.com)
5**
6** This file is part of the documentation of the Qt Toolkit.
7**
8** $QT_BEGIN_LICENSE:LGPL$
9** Commercial Usage
10** Licensees holding valid Qt Commercial licenses may use this file in
11** accordance with the Qt Commercial License Agreement provided with the
12** Software or, alternatively, in accordance with the terms contained in
13** a written agreement between you and Nokia.
14**
15** GNU Lesser General Public License Usage
16** Alternatively, this file may be used under the terms of the GNU Lesser
17** General Public License version 2.1 as published by the Free Software
18** Foundation and appearing in the file LICENSE.LGPL included in the
19** packaging of this file. Please review the following information to
20** ensure the GNU Lesser General Public License version 2.1 requirements
21** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
22**
23** In addition, as a special exception, Nokia gives you certain
24** additional rights. These rights are described in the Nokia Qt LGPL
25** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
26** package.
27**
28** GNU General Public License Usage
29** Alternatively, this file may be used under the terms of the GNU
30** General Public License version 3.0 as published by the Free Software
31** Foundation and appearing in the file LICENSE.GPL included in the
32** packaging of this file. Please review the following information to
33** ensure the GNU General Public License version 3.0 requirements will be
34** met: http://www.gnu.org/copyleft/gpl.html.
35**
36** If you are unsure which license is appropriate for your use, please
37** contact the sales department at qt-sales@nokia.com.
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*/
Note: See TracBrowser for help on using the repository browser.