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:
- Clutter+Cairo. Upsides: home-grown, good GTK+/GObject integration. Downsides: requires OpenGL hardware support
- 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
- 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?
Profile
jasondclinton- Jason D. Clinton
Page Summary
- (Anonymous) : do some research [+3]
- (Anonymous) : GNOME Mobile [+0]
- (Anonymous) : Go for Gtk+ 3.0 [+0]
- suppressingfire : (no subject) [+2]
- lester_dev : (no subject) [+0]
- (Anonymous) : Regarding Qt embedding [+0]
- (Anonymous) : Licenses [+2]
- rtcm : gtk+ 3 [+2]
- (Anonymous) : glitz and Cairo? [+1]
Comments
http://webcvs.cairographics.org/goocanvas/src/
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).
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
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.
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.
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.
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
http://www.freedesktop.org/wiki/Software/glitz
If I am wrong please enlighten me. I am just a "normal user" so maybe I miss some part of this puzzle.
best wishes
Achim