Re: Schrenckii: cairo, rsvg, pixmap, pixbuf woes

["Callum McKenzie" <callum spooky-possum org>]

This is definitely a tricky problem. At the end of the day pre-cached
pixmaps are the fastest way to do anything in an X server (without using
extensions like open-gl / shared memory / video stuff).

Option 1 is definitely to be avoided. Cairo is too slow for any animation
work. As, much to my shame, gnometris shows.

Option 2 is my prefered method. You can get around the transparency issue
by making a series of large pixmaps - one for each foreground image - with
the background image and the foreground image tiled across it. You then
copy the appropriate part of each image onto the main window as needed. It
chews memory, but only by a factor of the number of different tiles you
have.

The integer size thing isn't a big problem in practise. A few pixels
border isn't going to show much.

It does have some other problems: You can't let two adjacent tiles blur
into each other because the pixmap defines a sharp edge. Also resizing can
cause delays if you redraw all the pixmaps each time you receive a resize
event (aisleriot suffers from this). You can get around the resize problem
by updating the pixmaps incrementally and throwing away half-complete
pixmaps when the new resize event occurs (same-gnome does this, but the
code is awful to read).

As for option 3. This is the second-fastest route. The SVG natural size
problem is almost unavoidable. I seem to recall that the themes for games
like five-or-more had to have their SVG tweaked to get them to work
correctly. It can't really be fixed on the code side if I recall
correctly.

>   I am also
> going to be adding a strictly plain-block (like Gnometris) cairo-drawn
> option that doesn't require librsvg.
You could also use a good PNG theme and just use the pixbuf loader to get
the pixbufs. This is suitable for a fallback and should be very simple to
implement. Of course librsvg doesn't really suffer from the installation
problems that plagued it four years ago.

 - Callum