[Kde-games-devel] Improving theme authoring for kgoldrunner

[Parker Coates]

On Sat, Oct 24, 2009 at 06:41, Luciano Montanaro wrote:
> Another point: Ian said earlier that we have performance problems in theme
> loading: the theme graphics have to be loaded from disk on startup and parsed,
> which takes some time. The more complex the theme, the slower the game
> startup. That's not good...
>
> A solution could be improving caching, and not loading the svg file unless the
> window size changes and the tiles need to be regenerated. But this still means
> each window resize could involve along pause, before everything is rendered
> again.
>
> ...snip...
>
> The startup time reduction would resulting mainly from the fact that we do not
> load a gigantic svg file with many backgrounds, but only the background needed
> at the moment. And maybe we could use threads to load all the components in
> parallel. Even on single core machines, this should help.

Hey Luciano,

As far as threaded rendering and loading goes, you might want to have
a look at KCardCache and how it's used in KPat. In the run up to
KDE4.3, we noticed that the load times had gotten pretty bad. Sean had
just introduced the lovely Ancient Egyptians card deck, which while
beautiful, was significantly larger and more complex than any deck. He
later made some optimisation and brought size down, but it was still
obvious that we needed smarter card rendering.

At first I delayed loading the SVG and rendering of cards until we
came across a pixmap that wasn't in the cache. This help with start up
performance, but the first time an unrendered card was flipped over,
things ground to a halt while the file was loaded into the
QSvgRenderer and the pixmap was rendered. This was worse than the
delay at startup (even though it was a bit shorter) because it felt
like a much more significant interuption. I was also surprise at how
much time it took to just load the SVG into the QSvgRenderer,
especially for complex decks.

In the end, I (with Albert's assistance) fixed up and heavily modified
the threading loading in KCardCache. How things work now is:
1. KPat tells KCardCache which card deck/size to load.
2. KCardCache stores this information and opens the appropriate cache,
but doesn't yet load the SVG.
3. KCardCache launches an idle priority thread. (More on that in a bit.)
4. If KPat requests card pixmaps from the cache, KCardCache returns them.
5. If KPat requests card pixmaps that aren't in the cache, the SVG is
loaded (if it hasn't yet been) and the card is rendererd and returned.
6. Once the idle thread gets a chance to run it loads the SVG (if it
hasn't yet been loaded), checks to see which (if any) cards aren't
currently in the cache and then renders them all, returning them to
the main thread via signals and slots.

So lets say we just opened a new game of Spider but none of the
cards/sizes we need are cached. We're going to need some pixmaps as
soon as possible, so there's no way around it. We're forced to load
the SVG and render the face up cards in the main thread. Once the idle
thread gets a chance to run, it renders the front sides off all thos
facedown cards, so the pixmaps will be ready and waiting when it comes
time to flip them over.

On the other hand, if then shut KPat down and open up a new game of
Spider (with the same window size), all the pixmaps we need will
already be in the cache. So we don't load the SVG or render anything
in the main thread. When the idle thread runs, it'll see that it has
no rendering work to do, but it still loads the SVG, just so it'll be
ready if we need to resize the window.

This yielded significant performance improvements even on a single
core, non hyperthreaded system. On a modern multicore, it's especially
zippy. There is still plenty of room for further improvement of
course.

I realise that the above doesn't apply wholesale to KGoldRunner.
You'll need something simpler in some respects and more complicated in
others, but I hope the above was at least a little bit informative. If
there's one moral to take away, it's that loading an SVG can be as
expensive as rendering it, so delay or thread that whenever possible.

Parker