[Kde-games-devel] Proposing KGameRenderer

[Stefan Majewsky]

On Sunday 13 June 2010 00:04:02 Parker Coates wrote:
> In LibKCardGame, I do something even better. The loading of the SVG is
> delayed as you recommend, but then a low priority rendering thread is
> launched. The first thing the thread does is load the SVG after
> checking  it hasn't already been loaded. (It then goes on to render
> all card fronts and backs at the current size, but that's a separate
> topic.)

I have thought about how threaded rendering can be added. From what I see at a 
quick glance on the libkcardgame code, you try to render in a separate thread, 
but you allow rendering in the main thread when the app requests the pixmap.

In general, this is a good idea, but KGameRenderer (KGR) should make it 
possible to use asynchronously rendered pixmaps as much as possible, esp. to 
put today's multi-core CPUs to good use. (Having to render into a QImage, 
which is converted into QPixmap later, is not a performance hit because 
KImageCache stores as QImage anyway.)

The obvious interface to asynchronously rendered pixmaps is KGameRenderedItem. 
When a rendering thread has rendered an image, it is passed to KGameRenderer 
(in the main thread), converted to QPixmap, and distributed to all items which 
need this pixmap. I plan to add another class KGameRenderedSprite which can be 
used asynchronously when items are not the way to go (e.g. in KDiamond for the 
scene's background brush). The class would look something like this: (just a 
very compact sketch)

class KGameRenderedSprite : public QObject
{
    Q_OBJECT
    Q_PROPERTY(QPixmap pixmap READ pixmap NOTIFY pixmapChanged)
    Q_PROPERTY(QString spriteKey...)
    Q_PROPERTY(QSize renderSize...)
    Q_PROPERTY(int frame...)
    ...
};

If the sprite/item instance requests a new pixmap, KGR will try to serve it 
from the caches directly. If it is not cached, it schedules rendering of the 
pixmap in a worker thread. If the sprite has multiple frames, rendering of the 
following frames will also be scheduled (preferably with a lower priority) so 
that animations become available as quickly as possible.

RFC!

Greetings
Stefan