Log in

No account? Create an account

Previous Entry | Next Entry

Fixing Gnometris Performance

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.


( 22 comments — Leave a comment )
Apr. 9th, 2008 07:22 pm (UTC)
Why re-render at all?
Why not render it once and move the pixmaps instead? (In addition to invalidating the correct regions, of course.) I am astounded that tetris, which ran just fine on my 286 uses any CPU at all, for any reason.

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.
Apr. 9th, 2008 07:25 pm (UTC)
Re: Why re-render at all?
If I rely on pixmap graphics, non-orthogonal rotations, antialiasing and alpha-blending will not be possible when I want to implement the explosion effects. Sure they could be done with pixmaps, but then it would look like Tetris from the NES days.
Apr. 9th, 2008 07:28 pm (UTC)
Me too...
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..
Apr. 9th, 2008 07:42 pm (UTC)
The old theme is still there--available through preferences--and does not use Cairo so its just as fast as its always been.
Apr. 9th, 2008 07:57 pm (UTC)
Excellent work!
Excellent work on investigating and fixing the Tango performance problems in Gnometris!
Apr. 9th, 2008 08:21 pm (UTC)
Use OpenGL
Apr. 9th, 2008 08:29 pm (UTC)
Re: Use OpenGL
The Cairo glitz backend isn't currently usable.
Apr. 9th, 2008 08:37 pm (UTC)
2.22.0 with the Tango Shaded theme performs plenty well on my machine.

But maybe that says more about my machine than gnometris ;-)
Apr. 9th, 2008 08:38 pm (UTC)
Or are there some new animations in 2.22.1 that wasn't in 2.22.0?
Apr. 9th, 2008 08:39 pm (UTC)
No changes to Gnometris between 2.22.0 and 2.22.1.
Apr. 9th, 2008 08:39 pm (UTC)
keeping track of invalidated regions
GDK contains two methods that might help you:


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.)
Apr. 9th, 2008 09:46 pm (UTC)
Clutter Clue.
Use Clutter. It would be trivial with Clutter to make something like Tetris look fantastic and work really fast *effortlessly* without this kind of pain. It will need OpenGL (or OpenGL ES) but its the 21st century and Im sure for what little is actually needed to render even software mesa (for those in the 20th century) would be fast enough.

The GTK Clutter embedding widget is really shaping up nicely too.
Apr. 10th, 2008 03:57 pm (UTC)
Any chance that you could fix the background while you're making changes? I (as an semi-professional artist) really think it's awful and clashes with the rest of the colours and style. Just about anything would be better, including a plain beige background (see the whitest tango colour). I'll even make you something with whatever criteria you want if it'll be replaced. Please?

-- 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.)
Apr. 10th, 2008 06:28 pm (UTC)
Too complicated
The fact that you're worrying about update regions shows the frameworks you are using are incredibly lacking. You shouldn't have to worry about this stuff as an application dev. Doesn't gnome have a canvas library? If this is the best way to do things in 2008, with application devs worrying about optimizing painting performance, then there is something seriously broken in GTK.

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.
Apr. 10th, 2008 06:31 pm (UTC)
Re: Too complicated
There are three-four different 2D canvas libraries for GTK+; they are all considered dead projects because no used them and so there was no incentive to keep updating them.

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.
Apr. 10th, 2008 07:08 pm (UTC)
Re: Too complicated
Canvas libraries are incredibly useful in general, so if no-one used them, there were probably problems in the library.

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.
Apr. 10th, 2008 08:18 pm (UTC)
Re: Too complicated

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

Apr. 10th, 2008 09:16 pm (UTC)
Re: Too complicated
Well, KDE's plasma is entirely based on graphicsview. Don't know about the rest of KDE. And cairo isn't even remotely the same thing. From the types of questions that come up on qtcentre, I highly doubt that lots of people use Graphicsview for static vector drawing. Most applications involve some sort of interaction. Perhaps dragging objects or editing them in some way. There is very little need for graphicsview if there is no interaction. Static vector drawing is far lower level.

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.
Apr. 10th, 2008 07:45 pm (UTC)
Strange, on my laptop gnometris 2.22.0 consumes like 1-2% CPU even when maximized, theme: tango shaded
Apr. 10th, 2008 08:20 pm (UTC)
The field has to be 2/3 of the way full before you'll see it.
Jan. 27th, 2009 05:38 am (UTC)
Off the subject...
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.


Jan. 27th, 2009 05:45 am (UTC)
Re: Off the subject...
Subscribe to and send an email to games-list@gnome.org to get involved. I'd be happy to consider your ideas.
( 22 comments — Leave a comment )


color, uphair, smile
Jason D. Clinton

Latest Month

September 2011


Powered by LiveJournal.com
Designed by Tiffany Chow