[Kde-games-devel] Ideas for QML support in libkdegames
Viranch Mehta
viranch.mehta at gmail.com
Sun Mar 10 10:40:24 UTC 2013
On 09-Mar-2013, at 10:56 PM, Viranch Mehta wrote:
>
> On 09-Mar-2013, at 8:16 PM, Albert Astals Cid wrote:
>
>> To be honest the only solution i can think of is something similar. Put a
>> default background until all items are generated.
>
> There are two problems with this:
>
> 1. The area of the image to be rendered is painted with gray until the time rendering
> is finished, so even if we put a default background, it will be over-ridden by the gray
> area. one possible solution is to have "opacity: status==Image.Ready ? 1 : 0" in the
> items. this way it will stay transparent until its finished rendering. but this opacity
> transformation on every resize may be computationally expensive.
so what I came up with is we put a "fallback" image behind each sprite. this fallback image
will be same as latest sprite picked up from cache. now when window is resized (and the
source string changes), the original sprite will go invisible, and the fallback will be shown,
and as soon as the original sprite is rendered, it will be shown back in front of the fallback
image, and the fallback image internally will update to the just-rendered sprite image. this
will continue with the subsequent resize and so on.
I just pushed this to the branch in libkdegames, and this looks really better than the
previous gray areas. it also does not use any significantly more resources as the pixmap
is simply picked up from cache and no additional computation is involved for the fallback
image.
> 2. Exactly. we have no way of knowing when *all* of the requested images have
> finished rendering. (we could of course maintain an internal counter of requests vs
> replies but this sounds like a dirty hack).
this is not needed as the above solves our problem.
>
> Viranch
>
More information about the kde-games-devel
mailing list