[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] Proposing KGameRenderer
From:       Parker Coates <parker.coates () kdemail ! net>
Date:       2010-06-12 22:04:02
Message-ID: AANLkTil2C25YIlA4JfV0rHSDXEda3B7jObGkXSfiFRGW () mail ! gmail ! com
[Download RAW message or body]

On Sat, Jun 12, 2010 at 04:40, Ian Wadham wrote:
> I would suggest that the creation of a KSvgRenderer, SVG loading and
> SVG rendering can all be postponed until it is found that there is no cache
> or that it is invalid (e.g. SVG file more recent than cache) or that there is
> no cached pixmap with a required identity and size.   Also, loading is needed
> only when there is a theme change, as opposed to a size change.
> KGoldrunner::KGrTheme does that (i.e. it uses the cache alone in many
> runs of KGr) and that saves a *lot* of startup time (after the first run).

In LibKCardGame, I do something even better. The loading of the SVG is
delayed as you recommend, but then a low priority rendering thread is
launched. The first thing the thread does is load the SVG after
checking  it hasn't already been loaded. (It then goes on to render
all card fronts and backs at the current size, but that's a separate
topic.)

Originally, I was just delaying the loading, but I found that was
often less desirable then preloading since the SVG would sometimes
have to be loaded in the middle of game play causing a noticeable
pause. At least at startup the user is already waiting, so what are a
few extra milliseconds.. From my experience, loading the SVG in
parallel is definitely the ideal way of handling this.

Parker
_______________________________________________
kde-games-devel mailing list
kde-games-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

[prev in list] [next in list] [prev in thread] [next in thread]