[Kde-games-devel] Proposing KGameRenderer

[Stefan Majewsky]

On Wednesday 16 June 2010 20:00:26 Parker Coates wrote:
> Something that you didn't mention (or maybe just missed) is that
> [snip three paragraphs of techtalk]

Interesting. Seems like I should read the libkcardgame rendering code more 
carefully.

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

@all: Do you know a better word instead of "sprite" for "a pixmap which is 
retrieved from the SVG and which may have multiple frames"? Please not 
"element", because a "sprite" maps to multiple SVG elements when it has 
multiple frames.

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

Basically there are two possible options:
1. show an empty pixmap (i.e. nothing)
2. show the pixmap of the previous theme/size
I think there are scenarios for both behaviors, so this could be a flag of the 
KGR instance.

By the way, I think about adding a SynchronizePixmapRollout flag to KGR. When 
enabled, KGR will wait until all requested images have been rendered before 
sending the pixmaps to the Item/Sprite instances.

This could be combined with a (temporarily set) DisableAsynchronousRendering 
flag which could be set during program startup to avoid useless rendering 
operations after each of the bazillion resizeEvents.

Greetings
Stefan

P.S. Nice read about the iterators. I looked at the code in question, and all 
inefficient loops were of the type "foreach (CLASS* foo, bar)". Perhaps 
"foreach (const CLASS*& foo, bar)" would have been faster, but that's a big 
WTF IMO.