Re: svg cards 2.0 (pre1)

["Richard Hoelscher" <rah rahga com>]

David:

To get an exact read on how long it takes to render your cards, compile
librsvg from source and try the "test-performance" binary it provides.

David Bellot said:
>Callum McKenzie said:
>>On the rendering front: I'm not entirely sure what to do. For a resize
>>we could just rescale the pixmaps we have (this is quick) and then do
>>the hard rendering in the background so that the user faces fuzz for a
>>few seconds rather than a pause. This still doesn't help start-up time.
>>I don't think that librsvg is going to miraculously get faster either.
>>
> This is the kind of side-effect you can have with this program which
> changes the virtual screen by rotating a cube.
> If you look carefully, it rotates a smoothed texture of the screen and
> at the end of the rotation, it changes the smoothed texture with the
> real picture of the screen. It's not very annoying but it's not a nice
> effect too.

The pixbuf card rescale doesn't change the fact that we still need 3
seconds all at once when drawing that complex deck of cards, and during
that time the game would be frozen... I think a better way to hide the
delay may involve extending gnotski's idle method: Process configure
events, render the backdrop, then proceed with rendering only if the user
hasn't tried to resize the window since. This may help get rid of the
jerky resize problem, and is something I'll probably attempt a patch for
soon.

One long-term solution would involve rendering within another thread.
Unfortunately, after improved text support was added to librsvg last year,
it was discovered that the loader is no longer threadsafe because of
Pango.  Technically, it's possible to thread, but not realistic, as we
would have to ignore all rsvg_text calls: David Bellot's SVG would need to
have <text> tags removed, we would have to start filtering out files that
use <text>, and worst of all, gnome-games users are notorious for finding
heisenbugs.... Librsvg is in the process of removing that dependency, but
it probably won't happen during this release cycle.

As far as Cairo goes, I'll wait and see how it handles on my laptop
(800mhz, ATI Rage 128, but an awesome 1600x1200 screen) before saying much
of anything... Aside from this: Portions of librsvg are getting overhauled
(hi Caleb!) to support both Cairo and libart rendering, so drawing quality
should be good in either case.

-Richard Hoelscher
http://rahga.com/svg/