[Kde-games-devel] Ideas for QML support in libkdegames

Albert Astals Cid aacid at kde.org
Sun Mar 10 22:37:37 UTC 2013


El Diumenge, 10 de març de 2013, a les 16:10:24, Viranch Mehta va escriure:
> 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.

Had a look at kbreakout running with the new branch and looks pretty good on 
resizes now :-)

Should we review the code now? It's all in reviewboard or?

Cheers,
  Albert

> 
> > Viranch
> 
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel


More information about the kde-games-devel mailing list