digital home of MacSlow

I finally managed to motivate myself to update OpenGL examples with cairo with the current/new links to the hosting spots, where interested people can grab the example-sources. Over the last couple of weeks I got numerous requests regarding the stale links to the different examples listed on that page.

All examples have been migrated from git to bzr and put on launchpad. You can check out their sources from there. While doing that I also moved the repository of lowfat to launchpad. For lowfat’s code I also got a couple of “Where to grab the code?”-questions in my inbox. So now everybody should be happy and be able to easily get hold of the sources.

Here’s the quick list for the impatient readers:

• cairo-gimmicks
• bling-it-up
• gl-cairo-cube
• gl-cairo-simple
• gl-cairo-aatrick
• lowfat

Since glitz has been deprecated and completely removed from cairo’s source tree I also updated some of the examples, which used glitz-related code. So far I’ve not been able to add support for the new shiny cairo-gl backend, which the new coolness. I started on it, but stuff only segfaults around.

All that took so long because I can hardly force myself to do any spare-time hacking. It’s just not fun anymore, when you sit in front of the computer day in and day out. There are certainly tons of interesting things to do or try, but motivation is just zero.

Fixed the throbbing animation for over- and undershooting of the value indicator in notify-osd:

Note that this even works in the blurred/hover-over state.

Big, big, big thumbs up to the Xorg/Mesa-developer crowd and the hackers behind the intel-driver for OpenGL 2.x support (especially FBOs and GLSL)! Also big props need to go to Bryce Harrington and Alberto Milone for integrating this and pulling in all the needed bits and bytes into Ubuntu! It’s one thing to see stuff landing on f.d.o git, but only when it reaches “mere mortals” in the form of repository-updates it’s truly there (read: where the end-user “sees and feels” it).

“Yeah, yeah nice talking, Mirco. But what’s in it for me?”

Unless you’re not into developing OpenGL-based code yourself, but want to see direct results of this new feature-slickness in a full FOSS-GL stack, I’ve something for you… a screencast of course (make sure to download it to disk and play it back from there):

So there you have it. Under current Karmic Koala you can now enable the gaussian-based (read: good looking) blur. While that’s nice and dandy, this by itself does not mean much in terms of new features or productivity-enhancing applications. But it’s another important step towards OpenGL-feature-parity with the proprietary GL-drivers. BTW, what works here with my i965, should also work with ATIs R500-class GPUs under the free driver afaik. I think the free intel- and radeon/ati-driver are about at the same level of implemented features for i965 and R500. Not sure though about the R600 and R700. I guess they are a bit behind still.

Note: In this screencast you see two personal tweaks I maintain and usually carry around (read: reapply them on updates). That is to say, genie-look for the magic-lamp effect of compiz animation-plugin (gee, what a mouth-full *g*) and use of the blur-hint for compiz’ blur-plugin in libgksu.

If you like to try them yourself you can grab them for current Karmic Koala (upcoming Ubuntu 9.10) from my PPA here. Note that I do not always update these in my PPA once either libgksu or compiz-fusion-plugins-main got updated via normally published updates from the repository.

The pedantic reader now might ask, “Why don’t you push your patches to the relevant packages (or upstreams) proper?”. Regarding the blur-hint in libgksu the answer is, that my patch hardly would pass update-policy and this visual tweak is not part of Ubuntu’s visual features. Also we’re well past feature freeze. For the upstream-part of the answer is: Isn’t libgksu meant to be replaced by something else soon? So why bother shortly before the switch. Please correct me if I’m wrong here. For the patch to compiz-fusion-plugins-main the (upstream) answer is: The genie-look of the magic-lamp effect once was part of upstream, but was removed due to fear of some patent-issues. Still, I like the genie-look best, that’s why I “resurrected” this bit.

With the surface- and blur-cache available now, it is now also possible to animate the resizing (actually only “growing” will be used by notify-osd). Here’s a small unspectacular example screencast:

You can find this example in a branch of notify-osd here.

… and with this I’ll give you:

Edit: This of course works under compiz and metacity (+compositor). Under plain metacity you would not get the transparency against the desktop though. You can find this and other examples in a branch of notify-osd here.

Arrived at the hotel/summit. Going to head to the venue with a couple of folks soon.

And a small screencast for the day. Testing out the new blur-cache meant for notify-osd:

It’s easy on CPU. So light actually, that I was able to record this very screencast with recordmydesktop on a Dell Mini 9. This is finally also using the subtle text drop-shadow the design folks asked for. Color, font, size and all are just randomly picked by me, as this is a test-program to exercise the small interal APIs I created for implementing the blur-cache.

Edit: I forgot to mention it, that I’m doing this work in a branch currently. It’s lp:~macslow/notify-osd/blur-cache.

What the urgency-level bar-display looks like (see also here):

Corrected throbbing and proximity-fade in action:

Last but not least here is a sneak peak of work-in-progress on better and faster blurring:

I hooked up the cubic curve patch rendering to the preliminary cairo-path drawing. With it fonts look better now (compared to the first try).

The same clip on YouTube.

I feel happy now for the weekend

That’s what I did over the last couple of days. The reason was following the Loop/Blinn paper on “Resolution Independent Curve Rendering using Programmable Graphics Hardware” turned out to be harder than I first thought. Implementing just quadratic curves segments is a piece of cake compared to cubic cuves (read: Bézier curves). The dynamic generation of 3D texture-coordinates to feed the fragment-shader evaluating the cubic curve inequality v³ - wt > 0 is nasty. But I’m seeing a light at the end of the tunnel… or rather this:

There’s still much left to be done (and many bugs to fix), but piece by piece it’s getting there. The same clip on YouTube.

While working on this I also had a look at what a cairo rendering-backend actually needs to implement. Sofar I did not find hooks in a backends callback table to just hand over paths from cairo. That’s a bit unfortunate, because that’s what I want to be able to grab from cairo. I don’t want the decomposition to triangles/trapezoids to happen in cairo itself (on the CPU). That’s meant for the GPU. Well, it’s still a good stretch to go before it is time to thoroughly think about such issues. I assume folks on the cairo mailing-list help me sort things out, once the time has come.

I still have a few (vacation) days left before work starts again on monday. Let’s see what I can motivate myself to accomplish until then.

Remember that old cairo-demo. These days twirling text can actually be edited in real-time:

The same clip on YouTube.