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
|
/****************************************************************************
**
** Copyright (C) 2011 Nokia Corporation and/or its subsidiary(-ies).
** All rights reserved.
** Contact: Nokia Corporation (qt-info@nokia.com)
**
** This file is part of the documentation of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:FDL$
** GNU Free Documentation License
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file.
**
** Other Usage
** Alternatively, this file may be used in accordance with the terms
** and conditions contained in a signed written agreement between you
** and Nokia.
**
**
**
**
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\page qt-embedded-accel.html
\target add your graphics driver to Qt for Embedded Linux
\title Adding an Accelerated Graphics Driver to Qt for Embedded Linux
\ingroup qt-embedded-linux
In \l{Qt for Embedded Linux}, painting is a pure software implementation
normally performed in two steps. First, each window is rendered
onto a QWSWindowSurface using QPaintEngine. Second, the server
composes the surface images and copies the composition to the
screen (see \l{Qt for Embedded Linux Architecture} for details).
\l{Qt for Embedded Linux} uses QRasterPaintEngine (a raster-based implementation of
QPaintEngine) to implement painting operations, and uses QScreen
to implement window composition.
It is possible to add an accelerated graphics driver to take
advantage of available hardware resources. This is described in
detail in the \l {Accelerated Graphics Driver Example} which uses
the following approach:
\tableofcontents
\warning This feature is under development and is subject to
change.
\section1 Step 1: Create a Custom Screen
Create a custom screen by deriving from the QScreen class.
The \l {QScreen::}{connect()}, \l {QScreen::}{disconnect()}, \l
{QScreen::}{initDevice()} and \l {QScreen::}{shutdownDevice()}
functions are declared as pure virtual functions in QScreen and
must be implemented. These functions are used to configure the
hardware, or query its configuration. The \l
{QScreen::}{connect()} and \l {QScreen::}{disconnect()} are called
by both the server and client processes, while the \l
{QScreen::}{initDevice()} and \l {QScreen::}{shutdownDevice()}
functions are only called by the server process.
You might want to accelerate the final copying to the screen by
reimplementing the \l {QScreen::}{blit()} and \l
{QScreen::}{solidFill()} functions.
\section1 Step 2: Implement a Custom Raster Paint Engine
Implement the painting operations by subclassing the
QRasterPaintEngine class.
To accelerate a graphics primitive, simply reimplement the
corresponding function in your custom paint engine. If there is
functionality you do not want to reimplement (such as certain
pens, brushes, modes, etc.), you can just call the corresponding
base class implementation.
\section1 Step 3: Make the Paint Device Aware of Your Paint Engine
To activate your paint engine you must create a subclass of the
QCustomRasterPaintDevice class and reimplement its \l
{QCustomRasterPaintDevice::}{paintEngine()} function. Let this
function return a pointer to your paint engine. In addition, the
QCustomRasterPaintDevice::memory() function must be reimplemented
to return a pointer to the buffer where the painting should be
done.
\table
\header \o Acceleration Without a Memory Buffer
\row
\o
By default the QRasterPaintEngine draws into a memory buffer (this can
be local memory, shared memory or graphics memory mapped into
application memory).
In some cases you might want to avoid using a memory buffer directly,
e.g if you want to use an accelerated graphic controller to handle all
the buffer manipulation. This can be implemented by reimplementing
the QCustomRasterPaintDevice::memory() function to return 0 (meaning
no buffer available). Then, whenever a color or image buffer normally
would be written into paint engine buffer, the paint engine will call the
QRasterPaintEngine::drawColorSpans() and
QRasterPaintEngine::drawBufferSpan() functions instead.
Note that the default implementations of these functions only
calls qFatal() with an error message; reimplement the functions
and let them do the appropriate communication with the accelerated
graphics controller.
\endtable
\section1 Step 4: Make the Window Surface Aware of Your Paint Device
Derive from the QWSWindowSurface class and reimplement its
paintDevice() function. Make this function
return a pointer to your custom raster paint device.
\section1 Step 5: Enable Creation of an Instance of Your Window Surface
Finally, reimplement QScreen's \l {QScreen::}{createSurface()}
function and make this function able to create an instance of your
QWSWindowSurface subclass.
*/
|
