0
|
1 |
/****************************************************************************
|
|
2 |
**
|
|
3 |
** Copyright (C) 2009 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 |
*/
|