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

Viranch Mehta viranch.mehta at gmail.com
Mon Mar 4 13:10:46 UTC 2013


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.

*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



More information about the kde-games-devel mailing list