Log in

No account? Create an account

Previous Entry | Next Entry

Canvases, Games, and the Future Thereof

As an update to yesterday's post, two items of interest in the vector graphics rendering performance vein: Karl Lattimer (of gnome-system-monitor) reports a similar class of problem with rendering the hardware graphs, Ars Technica reports on GTK+ efforts to come up with a future vision of the toolkit that addresses the need for animation.

The Short Term

I will implement the trivial block-moving invalidation algorithm discussed yesterday. It's probably only 50 lines of code, or so. Hopefully, this will make it in to 2.22.2. So, that's the stop-gap measure that gives us the performance we need right now. However, this approach will not work with any kind of advanced animation. If we want pretty effects, we need a real canvas.

The Long Term

We need to decide if we want to adopt a canvas API in the 2.24-2.26 time frame so that we can start working on advanced animation effects. Alternatively, we can wait for GTK+ 3.0 which should provide the facilities that we need; there's no time frame for GTK+ 3.0.

The following canvas options are stable enough to consider for the 2.24-2.26 timeframe:

  1. Clutter+Cairo. Upsides: home-grown, good GTK+/GObject integration. Downsides: requires OpenGL hardware support
  2. Webkit+<canvas>-tag. Upsides: very easy programming interface, Webkit's canvas performance is phenomenal, sets a precedent for merging web-based games with desktop UI, good documentation. Downsides: yet another set of languages to maintain in Gnome Games, large surface area
  3. QtGraphicsView+QtGTK+-MainLoop support. By this option, I mean a QtGraphicsView would be embedded in a GTK+ UI. As progressive as our community is, I don't think people are open-minded enough to consider this even an option. Maybe you'll all surprise me with your responses, though. Upsides: hardware acceleration when available, good fall-back software rendering mode. Downsides: a new, large external dependency.

I should note that a11y and i18n are not considered features since all of our strings are in the GTK+ UI which has nothing to do with the playing field.

The fourth option is to just sit on our hands and wait for GTK+ 3.0.

Still thinking about all of this. What do you guys think?


( 19 comments — Leave a comment )
Apr. 10th, 2008 09:25 pm (UTC)
do some research
any reason you forgot goocanvas?
Apr. 10th, 2008 09:26 pm (UTC)
Re: do some research
It's dead?
Apr. 10th, 2008 09:43 pm (UTC)
Re: do some research
Actually, an examination of their mailing list and web site seems to indicate death but now that I look at their CVSweb, it appears that its still alive. Maybe that's an option. The non-visibility is disconcerting.

Apr. 10th, 2008 10:04 pm (UTC)
Re: do some research
http://webcvs.cairographics.org/goocanvas/ChangeLog?view=log and http://sourceforge.net/mailarchive/forum.php?forum_name=goocanvas-devel both indicate decisive non dead-ness

You should also check out http://live.gnome.org/ProjectRidley/CanvasOverview

Goocanvas was discussed for inclusion in Gtk sometime last year. The proposal was Havoc'd. The inclusion discussion seemed to destroy most of the motivation of Damon (the goocanvas maintainer).
Apr. 10th, 2008 09:50 pm (UTC)
GNOME Mobile
Clutter sounds a good option if you take into account the support for OpenGL ES, something that modern devices are including
Apr. 10th, 2008 10:37 pm (UTC)
Go for Gtk+ 3.0
Neither of the solutions you propose are real replacements for a Gtk+ animation framework. The only viable option (IMO) is the step to Gtk+. Let me explain.

Right now, everyone working with advanced graphics and animation on Gtk+ is having performance problems. However; most of those problems can be de-escalated by providing hacks. Those hacks are pure short-term solutions, but most of them are, I'd guess, rather easy. All the dirty 2D-tricks that game programmers used to squeeze out some performance. Pre-rendering of Cairo surfaces to bitmaps, maybe.

In the long term, the road to Gtk+ can be paved and prepared. Some features requiring no ABI break might even get backported. And with graphics fixed for short-term, there may be more smart brains to fix Gtk+ 3.0. :D
Apr. 10th, 2008 10:45 pm (UTC)
I guess there are a few more alternatives, including Immiendo's Elisa's Pigment and a number of more straightforward cairo-based canvases (the already mentioned goocanvas, Mugshot's hippocanvas, libccc, and maybe a few others). The cairo-based ones may need work to provide high speed performance, though maybe they're fast enough for simpler things like tetris.
Apr. 10th, 2008 10:55 pm (UTC)
pigment is developed by Fluendo, not Imendio (and it's not even spelled Immiendo anyway). and it's python-only, even though it has a C core - offering very little to the developer (it's as rough as GL).

cairo can provide high level 2D performance, but suffers from the same problems GL has: some drivers are broken - and that's why gnome-games and gnome-system-monitor have issues with straight on cairo.
Apr. 10th, 2008 11:11 pm (UTC)
Sorry, thanks for corrections ;-)
Apr. 11th, 2008 12:17 am (UTC)
I think, the first way is a way of choise. Almost all video hardware has drivers with opengl support nowadays (at least ones I personally saw). Even Via has stated they will improve a linux compatibility with their drivers. So I hope when the gtk+3.0 will be ready there won't be even a thought about lack of opengl support.
Apr. 11th, 2008 12:36 am (UTC)
Regarding Qt embedding
Regarding the third option, embedding QtGraphicsView. I don't think that's so much a political problem as simply a technical one - it means dragging in an awful lot of complexity that's probably not worth the gain. On the other hand, a port of the Qt code to native Gtk/Cairo might be reasonable - particularly if done in such a way to keep the two versions in sync, ala KDE and Gtk branches of WebKit...
Apr. 11th, 2008 08:10 am (UTC)
QGraphicsView would be impossible from a licensing standpoint, as I see it.

It isn't just a matter of progressiveness, the problem is that by introducing a GPL library into the GTK codebase, it effectively all becomes GPL, instead of LGPL. GPLing GTK has downsides, precisely because of which GTK is LGPLed. In particular some of the popularity of GTK is because of its licensing, not just its quality.

Furthermore, QGraphicsView's copyrights, and hence licensing, are controlled by Nokia. The current situation is that it is GPL2/3/other options, but for example we have no assurance that GPL4 will ever be an option, when the time comes. So in 5-10 years we might have a serious problem. This isn't an issue with the LGPL, and it would be a far simpler problem if e.g. the FSF held the copyrights instead of Nokia.

Personally, I vote for some form of extension of Clutter. Yes, it requires OpenGL, however, software rendering can be reasonable for simple UIs, and this can also be improved performance-wise in the future. Clutter has a nice API, is GObject-based, and fun to work with in my experience.
Apr. 11th, 2008 02:56 pm (UTC)
Re: Licenses
You completely misunderstand. Embedding a QGraphicsView widget in a GTK UI makes the application GPL; it has absolutely no affect on the rest of Gnome. It's a one-time embed; it doesn't get incorporated in to GTK *at all*.
Apr. 12th, 2008 07:57 am (UTC)
Re: Licenses
I appreciate that. But the problem remains.

If any app that wants to use this approach must be GPL, then that is in fact the exact same result as if GTK itself were GPL. The only difference is that this applies only to apps that actually use the canvas, but since this is a pretty important piece of infrastructure - whose usage is expected to rise - the consequences are requiring many apps to be GPL (and, specifically, the GPL versions acceptable to Nokia).

In other words, if GTK were GPL, apps would need to be GPL; if GTK apps are expected to use the Qt canvas, they must also be GPL; the result is the same, at least for apps using the canvas.

This goes against the LGPL approach of GTK, and introduces additional complexity in that there are now more relevant licenses that developers for GTK platforms must understand.
Apr. 11th, 2008 01:12 pm (UTC)
gtk+ 3
I think the accepted plan[1] for gtk+ 3.0 is to NOT include new features like the canvas you describe. It's meant to be a sanitized API release. New features are planned for later releases like 3.2, 3.4, etc.

Anyway, have you reported your performance problems to the cairo ML? Carl Worth and his crew are bunch of great hackers that would surely help you with ideas to overcome these problems.

Good luck!

[1] http://inverted-tree.livejournal.com/58280.html
Apr. 11th, 2008 01:14 pm (UTC)
Re: gtk+ 3
Sorry I've just now seen that you have indeed already talked with Carl Worth.
Apr. 11th, 2008 01:14 pm (UTC)
Re: gtk+ 3
Sorry I've just now seen that you have indeed already talked with Carl Worth.
Apr. 13th, 2008 08:14 pm (UTC)
glitz and Cairo?
I am wondering if glitz is the solution.


If I am wrong please enlighten me. I am just a "normal user" so maybe I miss some part of this puzzle.

best wishes
Apr. 17th, 2008 10:45 am (UTC)
Re: glitz and Cairo?
glitz is unmaintained, and has been for years now. it's also heavily relying on shaders and other high end cards features that are available either by using a new intel card or closed source drivers.
( 19 comments — Leave a comment )


color, uphair, smile
Jason D. Clinton

Latest Month

September 2011


Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow