|  | Home · All Classes · Main Classes · Grouped Classes · Modules · Functions |

[Contents]

# Adding an Accelerated Graphics Driver

Qtopia Core uses Qt's premade raster-based implementation of QPaintEngine (`QRasterPaintEngine`) to implement painting operations. In addition QScreen implements window composition. Both are complete software implementations.

Painting is normally performed in two steps: each window is rendered onto a QWSWindowSurface using QPaintEngine, and then the server composes the surface images and copies them to the screen. The first thing you normally want to do is creating a subclass of QScreen and accelerate the final copying to the screen by reimplementing QScreen::blit() and QScreen::solidFill(). Further acceleration may be achieved by subclassing the QRasterPaintEngine. Note that this is still work in progress, and details are subject to change.

## Subclassing QRasterPaintEngine

QRasterPaintEngine inherits from QPaintEngine, so to accelerate a graphics primitive, simply reimplement it in your QRasterPaintEngine subclass. If there are cases you do not implement yourself (such as certain pens, brushes, modes, etc.), just call the QRasterPaintEngine version.

To activate a subclass of QRasterPaintEngine you need to create a subclass of QCustomRasterPaintDevice and reimplement QCustomRasterPaintDevice::paintEngine(). Note the QCustomRasterPaintDevice::memory() function which must must be reimplemented to return a pointer a buffer where the painting is to be done. You must then create a subclass of QWSWindowSurface and return your QCustomRasterPaintDevice in QWSWindowSurface::paintDevice().

Finally, reimplement QScreen::createSurface() to return your QWSWindowSurface subclass.

## Acceleration Without a Framebuffer

If you are writing a driver for a device with an graphic I/O controller and no framebuffer support, you need to subclass QRasterPaintDevice as described above. However, QCustomRasterPaintDevice::memory() must in this case return 0, meaning no buffer available. In this case the two fallback functions QRasterPaintEngine::drawColorSpans() and QRasterPaintEngine::drawBufferSpan() is called instead whenever a color or buffer should be written into memory. You can then reimplement these functions and do the appropriate communication with the I/O controller instead.

[Contents]