[Kde-games-devel] Proposing KGameRenderer

[Parker Coates]

On Wed, Jun 16, 2010 at 16:51, Stefan Majewsky wrote:
> 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.

Something that you didn't mention (or maybe just missed) is that
rendering happens in the main thread *only* if we have absolutely no
existing pixmap for that card. If we do have an existing pixmap we do
either or both of the following:

- If the existing pixmap is from the previous theme, we use it until
the equivalent pixmap from the new theme has been returned from the
other thread.
- If the existing pixmap is the wrong size, we do a quick and dirty
rescale to the correct size.

So rendering occurs in the main thread only when the only other option
would be to display nothing. In this particular case I decided it was
worth a short delay to avoid the potential confusion that could stem
from game elements being invisible. LibKCardGame also stores the last
used item size in the cache, so that on start up we can load the
pixmaps from the previous run to use as our "existing" pixmaps. If you
check the debug outfit from KPat and resize the windows, change
themes, etc. you'll see that very rarely to things end up being
rendered in the main thread.

> 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.)

I hadn't considered this benefit, but you are right. That removes one
extra QPixmap->QImage conversion for each rendered pixmap, which is
nothing to laugh at.

> 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...)
>    ...
> };

Okay, now I *really* object to using the word "sprite". :D Since this
class could be doing practically anything, I hardly think the word
sprite is appropriate anymore. Maybe something nice and abstract like
KGameRendererClient? I don't really know. Is your intention to make
KGameRenderedItem inherit from this class? I think that would make the
most sense.

> 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.

I guess I'm wondering what you plan to do in between the pixmap being
requested and the rendering thread returning it?

> RFC!

Nothing you describe seems incredibly stupid ;) but to know for sure
whether it'll actually work, I think you'll have to actually implement
it. There are a lot of small, easily overlooked details when doing
this kind of work.

Parker