In 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 Qt for Embedded Linux Architecture for details). 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 Accelerated Graphics Driver Example which uses the following approach:
Warning: This feature is under development and is subject to change.
Create a custom screen by deriving from the QScreen class.
The connect(), disconnect(), initDevice() and 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 connect() and disconnect() are called by both the server and client processes, while the initDevice() and shutdownDevice() functions are only called by the server process.
You might want to accelerate the final copying to the screen by reimplementing the blit() and solidFill() functions.
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.
To activate your paint engine you must create a subclass of the QCustomRasterPaintDevice class and reimplement its 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.
Acceleration Without a Memory Buffer |
---|
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. |
Derive from the QWSWindowSurface class and reimplement its paintDevice() function. Make this function return a pointer to your custom raster paint device.
Finally, reimplement QScreen's createSurface() function and make this function able to create an instance of your QWSWindowSurface subclass.
© 2008-2011 Nokia Corporation and/or its subsidiaries. Nokia, Qt and their respective logos are trademarks of Nokia Corporation in Finland and/or other countries worldwide.
All other trademarks are property of their respective owners. Privacy Policy
Licensees holding valid Qt Commercial licenses may use this document in accordance with the Qt Commercial License Agreement provided with the Software or, alternatively, in accordance with the terms contained in a written agreement between you and Nokia.
Alternatively, this document may be used under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation.