Funky cairo!
This is something I wanted to get out there before 2007… more cairo-utilization love. Soon you will get two new tutorials at cairographics.org/OpenGL. You will get some nice examples of how to setup your gtk+/cairo-programs with a glitz-backend, some funky effets with cairo and a nice trick for free anti-aliasing (under certain conditions) in OpenGL using cairo as a helper. As a little appetizer have a look these screencasts from one of the examples (glitz-cairo):
 (click to play back, ogg/theora, ~1.3 MBytes) |
 (click to play back, avi/h.264, ~4.7 MBytes) |
Since we are nearing 2007 and composited environments get more common, it should be taken for granted to have glitz-test be composite-aware. Here’s the proof, that this is really the case:
 (click to play back, ogg/theora, ~1.3 MBytes) |
 (click to play back, avi/h.264, ~4.7 MBytes) |
Sourcecode will come too, don’t worry. But I have to party right now and do funky stuff of the other kind this night *g*
So, I hope you all had a merry christmas and will have supreme 2007… see you all next year!
December 31st, 2006 at 11:38 pm
Beautiful!
Could this make it into GTK too? I mean, to make widgets aware of compositing effects… QT (already working on it, according to Zack Rusin), Aqua and Vista have that kind of support in their GUI toolkits…
Anyway, this is very cool!
Cheer, and happy new year!
Marcelo
January 1st, 2007 at 1:51 am
Good work your making there.
January 1st, 2007 at 2:18 pm
Nice work man. I’ve been hacking with OpenGL and cairo myself, and I have a question you might be able to answer: Does cairo drawing with the glitz backend allow for procedural textures on OpenGL surfaces, or does the vector graphics have to be rasterized to a bitmap image and then applied as a texture?
In your gl-cairo-cube (which uses cairo-image-surface if I remember correctly) the textures are rendered into memory and then loaded with glTexImage2d(). This means that the textures aren’t resolution independent.. But if fragment programs could be used to do the drawing on the OpenGL surface it could be completely procedural (as opposed to rasterized) and completely resolution independant.
January 2nd, 2007 at 12:51 pm
@Marcelo Fernández: What you are seeing there is a gtk+ program. The thing you mentioning by "make widgets aware of compositing effects" is in place already in gtk+ 2.10.x, e.g. you draw everything with cairo in a gtk+-theme engine and branch your rendering-code for composited and non-composited environments thanks to the call gdk_screen_is_composited(), thus you can have you theme-engine/widget rendering-code act accordingly. The "only" thing missing in gtk+ is offscreen rendering and a canvas-like thing to simplify creating animated transition effects (read: UI-toolkit level effects).
@Ramsees: Thanks, you’re welcome
@ Markus Jonsson: Yes it has to be rasterized at the moment. gl-cairo-cube is a terrible CPU-hog due to this (depending on the used texture-size). Using vertex- and fragment-programs for truly (implicitly) resolution independent OpenGL-textures would be a nice project to undertake… do I hear you volunteer? *g*
January 2nd, 2007 at 5:41 pm
MacSlow: I’ll most definitely give it a try. Don’t know if my experience is enough.. The Cg theory is there though.
In what IRC channel do you hang out?
March 5th, 2007 at 11:08 pm
All this is great work, thanks for making it available!
There is something that confuses me, after testing this: I get up to 20fps with glitz enabled and from 5 to 10 without, so glitz give me something. But I don’t understand how it can actually be slower than the gl-cairo-cube test that runs several of these demos at the same time and doesn’t uses glitz. Am I missing something w.r.t. the rendering path or whatever ?
I use nvidia drivers 97.46 on 6600GT (p4 2.6Ghz)