Re: gnome-games 2.16.0 released and branched for 2.17



On Mon, 2006-09-04 at 21:18 -0500, Richard Hoelscher wrote:
> Jason D. Clinton said:
> ...
> > Known issues:
> >
> >       * Rasterizing the Mahjongg and Aisleriot playing field takes too
> >         long with the current SVG code paths. We, in cooperation with
> >         the Cairo team, hope to optimize this rendering speed during the
> >         maintenance of the 2.16 series.
> 
> Continuing my series "SDL is not an easier OpenGL, and 132 other
> gnome-games misconceptions", and since I just can't commit with certainty
> to work on this within gnome-games anymore [*]...
> 
> The problem has nothing to do with rasterizing the playing field, and
> Cairo is a non-issue. Cairo does immediate mode drawing, and is great for
> quickly rendering a scene once, but not several frames per second of
> complex graphics like card decks. Aisleriot is using Cairo right now
> within librsvg to render the decks to pixmaps. Aisleriot then moves those
> pixmaps. THIS WORKS FINE. Going completely Cairo would be a bit like
> playing solitaire in Windows Vista without a graphics accelerator, except
> that Microsoft has the advantage of using raster images yet performance is
> still horrible.

At no point have I said that we're moving to Cairo. librsvg is using
Cairo to render to a pixbuf surface, as you mention. Carl Worth
contacted me about the above issues as a good test case for the
gnome-performance list work that is going on right now. Don't read
anything more in to the announcement. That is all that I mean by the
above.

> The problem is that SVGs for card games tend to be large, and Aisleriot
> renders the entire deck in one pass because of the monolithic deck format.
> It can't kick it out to another thread because of non-threadsafe Pango
> (IIRC ATM). As long as you are doing this, resizing the window or starting
> the game will always hit a delay. The only real solutions are split the
> elements into multiple SVG files, or to tag the elements with a name that
> librsvg can use to render (then render each element during and idle loop,
> yada yada...). While I had a testcase working for the latter in Mahjongg,
> I'm afraid this would just be another solution that absolutely nobody in
> the Inkscape community would grok because they (a) don't have decent layer
> support, and (b) a scared stiff of text editors and XML [*].

Or the existing librsvg calls could return much quicker which is what
we're shooting for.

> -Richard Hoelscher
> 
> 
> [*] ... Among other things, bugs like #352084 simply broke my will to hack.

"Fullscreen menu item changes when selected"

Huh?

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]