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

[Albert Astals Cid]

El Dilluns, 4 de març de 2013, a les 18:40:46, Viranch Mehta va escriure:
> Hey all,
> 
> I spent last weekend working on differenct ideas for having QML support in
> libkdegames - the main issue being the theme loading. I came down to two
> designs:
> 
> ====
> 
> *1. Use QDeclarativeImageProvider instead of KGameRenderer:*
> Here we supply our KgThemeProvider(s) to the QML engine, which adds our
> KgImageProvider with the supplied KgThemeProvider(s) to the QML context.
> 
> the KgImageProvider is a subclass of QDeclarativeEngine that talks to the
> supplied KgThemeProvider to get path to svg and use QSvgRenderer to render
> the particular spriteKey requested.
> 
> the trick with enabling changes in the images on theme update is to include
> the theme name in source's value-
> "image://myimageprovider/EgyptianTheme/Background". so whenever theme is
> updated, source url will change and new image will be requested frm the
> KgImageProvider.
> 
> Pros:
> 1. QDeclarativeImageProvider has inbuilt ability of caching and asynchronous
> loading, so we can get rid of KGameRenderer altogether in QML ports.
> 
> Cons:
> 1. When game window is resized, sprites of new size have to be naturally
> retrieved from the SVGs, but QDeclarativeImageProvider is not triggering a
> new request, its resizing the pixmap from cache. we could overcome this by
> adding dimensions to source string, change in which would trigger a new
> pixmap request, but that seems over-usage of source parameter IMO.

Not really, you are asking for 
image://myimageprovider/EgyptianTheme/Background/1920x1080
that is the image that i want to use at 1920x1080, at a different resulution 
might even be a different image, not just a rescaled one, i don't think it's 
over-usage to be honest.

Cheers,
  Albert

> 
> *2. Make KGameRenderer a QML component*
> Here we declare all our KGameRenderers in QML itself:
> 
> Renderer { source: "appdata/themes" }
> 
> The component internally will split source string with "/" and use the
> tokens with KgThemeProvider to discover themes and load sprites from them.
> 
> The problem of missing default constructors in KGameRenderer and
> KGameRendererClient are also fixed by implementing them :) I tried this and
> doesn't seem to break anything.
> 
> Pros:
> 1. Graphics are polished as pixmaps of correct size are given by
> KGameRenderer.
> 
> Cons:
> 1. The overall speed becomes little slow in comparision to Design1, as each
> resize triggers a request for new pixmap.
> 2. we need to supply the underlying KgThemeProvider to KgThemeSelector to
> change themes during gameplay. with above approach, we'll have to dig deep
> in QML context to extract the KgThemeProvider object, which seems dirty.
> 
> ====
> 
> Basically we have trade offs between performance+good-way-to-do-it and
> graphic quality.
> 
> Ideas on these would be great.
> 
> Cheers,
> Viranch
> 
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel