I had the pleasure of discussing Cairo and Gnome Games with Carl Worth a few days ago. As many have noted, the new Tango theme in Gnometris will bring even the most powerful systems on the market today to its knees once the playing field is about two-thirds of the way full.
As it stands today with Gnome Games 2.22.1, we invalidate the entire field, and call Render::render to rerasterize the playing field when any animation occurs: a block moving, a line cleared. This worked well when Gnometris was just moving simple pixmaps around. Now, the gradient and tessellation calculations inside Cairo are too hard to stick with this method.
Since I'm rather new to canvas programming, my first inclination was to approach the problem by going back to pixmaps: rasterize the Tango blocks to off-screen pixmaps, then go about the animation using the old, invalidate-and-repaint-everything method. Well, I've been informed that there are cleverer ways of approaching vector animation. I'm sure that anyone with any experience in graphics probably already got this memo; but, it's new to me, so maybe someone else can appreciate the following explanation.
Consider the following animation event: a block falling 1U.
Gtk+ (and Cairo) allow us to selectively invalidate-and-rerender a region of a window. In the Gnometris case, calculating the region that needs to be updated is trivial. The region invalidated by a block falling 1U looks like this:
So, all I have to do now is find time to modify Render::render to accept a region to update as an argument and do a little math to figure out invalidated region to hand to it. In the case of a line being cleared, (almost) everything moves, so rerendering the whole field is reasonable.
Looking toward the future, I would like to add some explosion-style animation to Gnometris. When a line is cleared, the deleted blocks explode and fade away while the blocks above side down with innertia-like physics and "crunch" with residual vibration on the blocks below. To make this happen with Cairo, I would need very smart, aggressive region invalidation and more efficient manipulation of the vector data on the playing field.
If anyone knows of a library that can help with calculating all the invalidated regions, please let me know or post to the games-list.

Comments
Sorry for sounding rude. This points to the bigger problem of why software today consumes so much more resources than it used to and does very little more.
I was Gnometris addicted ... then it didn't work anymore... and also the old good theme was quite fancy..
I knew it it will come to life again..
But maybe that says more about my machine than gnometris ;-)
gdk_rectangle_intersect
gdk_rectangle_union
You would just need to keep a list of "dirty rectangles" and, when adding new ones to the list, union any intersecting rects. (If the dirty list starts to get too big on a given frame, you typically just do a full redraw.)
The GTK Clutter embedding widget is really shaping up nicely too.
-- Andrei Thorp of Garoth.com (Should be easy to find my e-mail if you want me, though I know you gnome guys have your own artists.)
I'm just a regular joe dev, but I develop some OSS for fun, and if I had to worry about trivial low-level stuff like this in my frameworks, I definitely wouldn't bother.
Until recently, only Gnome Games did any animation. If you don't need animation, there's really no good reason to use a canvas library. Thus, no one used one.
There is Clutter, which I am looking at. It required OpenGL hardware.
Even without animation, there are plenty of good reasons to use canvas libraries. Just visualizing many items of any type, perhaps interacting with them in some way. For example, any sort of diagramming app (like Dia) is an ideal candidate. Look at how often graphicsview is used in Qt. It's incredibly popular, even though it was only released a shortish amount of time ago.
Clutter looks really cool, but the OpenGl requirement is a deal breaker for me. OpenGL is just not an option with today's graphics driver situation on Linux. Fine for games or Compiz, but if it can be avoided, it should. There are far too many machines that just have garbage drivers that don't support any 3D acceleration. You can't really make an app that shuts out all those people as potential users.
In Gnome, we have Cairo to do what most people use Qt GraphicsView for. As far as I know, the only people using Qt GraphicsView for actual animation in KDE are the KDEGames people--for the exactly the same reasons that I write about in this blog entry. As far as I know, all other uses of GraphicsView in KDE are for the same purpose that Cairo is currently used in Gnome: a static, vector drawing surface.
To get the same features as Qt GraphicsView in Gnome, it appears we need to mix Cairo and something like Clutter.
Just yesterday, Ars did a great write-up about this confusion and how it might all be unified in the future. It's a good read and quite educating: Reinventing GTK
The Qt equivalent to Cairo is the Arthur paint system. Since that's the underlying painting system, it's used by all apps, similar to how cairo is used in GTK.
I'd really like add some sound to this game(gnometris), personally. Some custom music? Custom sounds?:) Can you tell me who I should be talking to about this? This game + kasteroids would be really fun to work on but I can't seem to find the right contacts:( Any help would be much appreciated.
-Adam
adamspade@helixcomputer.com