Qtopia Core 4.2 Screen Drivers

Материал из Wiki.crossplatform.ru

Qt Quarterly | Выпуск 19 | Документация

by Hеvard Wall

[править] Multihead Support

QScreen now features two virtual functions that can bereimplemented by subclasses to support multiple screens:

QList<QScreen *> subScreens() const;
QRegion region() const;

app -qws -display "Multi: QVFb:0 QVFb:offset=640,0:1 VNC"

The coordinates passed to your reimplementations of QScreen's virtual functions are always specifiedin global coordinates. In most cases, your existing custom drivers will workwith no change, but if you perform some kind of lookup in a data structurethat assumes the screen's origin is (0, 0), you will need to subtractQScreen::offset() to convert the globalcoordinates into screen coordinates.

[править] Window Surface Abstraction

Qtopia Core 4.2 introduces "window surfaces" as a mechanism to control the memory used when painting a QWidget.This provides a way to accelerate painting beyond what is possible byreimplementing QScreen's solidFill() andblit() functions. To support window surfaces, these factory functionswere added to QScreen:

QWSWindowSurface *createSurface(QWidget *widget) const;
QWSWindowSurface *createSurface(const QString &key) const;

QWSWindowSurface is the abstraction of thearea a top-level QWidget (i.e., a window) is drawnonto. By default, if you are creating a window in the QWS server, this will bea chunk of local memory. If you are creating a window in a client process, itwill be a chunk of shared memory. And if you set theQt::WA_PaintOnScreen attribute on the window, it will be an areainside the framebuffer. This default behavior can be overridden byreimplementing the createSurface() functions in a subclass.

If you're writing a driver for a device with little memory and noframebuffer, you probably want to avoid drawing into memory at alland rather use an I/O controller to send drawing commands directlyto the video card. To achieve this, you would subclass QWSWindowSurface to avoid the memoryallocation and reimplement the paintDevice() function to return a QCustomRasterPaintDevice subclass.The paint device's paintEngine() function would return an instance ofan accelerated paint engine.

[править] Writing an Accelerated Paint Engine

Writing an accelerated paint engine consists of subclassing QRasterPaintEngine and reimplementingthe following two virtual functions, which are new in Qtopia Core 4.2:

void drawColorSpans(const QSpan *spans, int count,
                    uint color);
void drawBufferSpan(const uint *buffer, int bufferSize,
                    int x, int y, int length,
                    uint constantAlpha);

These functions are only called if the paint device's memory()function is reimplemented to return 0. The drawColorSpans()function is called to draw one or more spans with the given coloron the screen. The drawBufferSpan() function is called to draw abuffer of pixels from memory.

Be aware that both QWSWindowSurface andthe accelerated paint engine technique described above are included in QtopiaCore 4.2 as "preliminary APIs", meaning that they may change in a laterrelease.