Guadec ’08

Been putting off writing about this for a while, but it’s getting on a bit, so a ‘short’ blog post is in order, I think. Guadec ’08 was pretty awesome. I was expecting it to be a little stale, not so many of the talks sounded that exciting, and all the talk about decadence/stagnation (poppycock!) probably lead me to have negative preconceptions. That just meant that some of the excellent talks that there were were even better, as they came unexpected.

OpenedHand, of course, had some excellent talks, but I guess this goes without saying by now. Clutter just gets more and more interesting (go check out the new 0.8 release, recently accompanied by 0.8 releases of the gtk, qt, gstreamer and cairo integration libraries!), as do our surrounding applications and technologies. Guadec always seems to get me coding on Dates-related bits – ’06, I rewrote the event-fitting and query code in Dates (making it usable on the tablets), ’07 I started writing libjana (as used in openmoko-dates and openmoko-messages, amongst other things) and this year, I wrote vala bindings and started some work with glade3 integration. Unfortunately still a ways to go on the latter, but I hope it’ll provide the foundation of Dates 2, eventually. I will delivery on that pledge, honest!

Istanbul was an excellent location for guadec and is a really interesting and entrancing place. Anyone reading p-g-o would have seen the multitude of picturesque photos being spammed about the place, but the coolest thing with Istanbul is that it really is like that, everywhere you look. It must be awful for OCD photographers, there are so many picture opportunities. Even with my camera-phone, I managed to capture some (what I consider) great photos. It’s a close match between Istanbul and Catalonia, but I think Istanbul just about pips it. One thing that Istanbul couldn’t quite match was the very cool atmosphere that there was at the Villanova (sp?) cabin site. Having everyone in one place, with easy transportation to the event was really nice and it’d be cool if that were repeated in future guadecs somehow.

Outside of the businessy aspect of guadec, I had a great time jamming with the Drooling Macaques. Hats off to the guys (Lucas, J5, Alberto, Carlos, Claudio, Edward, Rob, Thomas, Lefty, Jono, I don’t think I missed anyone?), especially for putting up with my terrible drumming! I’ll be better for next year ๐Ÿ™‚ Also, kudos to Collabora and whoever else was involved in setting up the awesome boat party. Was a lot of fun, although I’m sure some others partied a lot harder than I ๐Ÿ˜‰

As for all this GTK+3.0 talk, I think Karl’s post is a pretty good short-list of features that I’d like to see in a new major version. To that list, I’d add easy event redirection, a w3c style bubble/capture event system and for there to be a scrollable interface, as opposed to some crazy, hard-to-implement, totally undocumented, magic way of creating scrolling widgets (no, I’m not bitter…) Also, better input method integration/control (from the program side as well as the user interface side) wouldn’t go amiss. Past this, I don’t think there’s that much more necessary… For next generation interfaces, we have Clutter. Once we can embed GTK inside Clutter reliably (off-screen is coming in 2.x, right? That just leaves easy event mangling/synthesis/redirection?), all sorts of crazy shiz can go down. At the end of the day, I suppose it’s down to the people that will be doing the work. If the majority of GTK devs think there needs to be a new major version, I trust them to make the right decision – they did a pretty bang-up job on 2.x ๐Ÿ™‚

As for Gnome 3.0, I think the future of HCI lies in more specialist devices and ubiquitous/pervasive computing that it does on the desktop. I’d like to see a Gnome 3.0, just because I think it’d be very interesting and I like to play with new toys, but I don’t think it’s something that’s *necessary* per se. Certainly there’s still quite a ways to go in polishing what we already have.


Clutter-gst, now with 100% more shaders

Just committed shader support to clutter-gst. When your card supports it and gstreamer decides it’s the format to use (often it picks rgb over yuv, I’ve no idea why this is), YUV decoding will now be handled by a pixel shader instead of the CPU. This should give a reasonable boost when it gets used (in terms of CPU use).

Even more interesting in my eyes, is the YV12 shader I’ve also committed. Normally YV12 hardware-assisted decoding would be done with 8-bit textures and multi-texturing. This is also the sensible way to do it, mind, and I do realise that… But also committed, is a YV12 shader that will decode YV12 uploaded into a 24-bit rgb texture. I’ve not seen a shader that does this before, probably because it’s an insane thing to do, but if you build clutter-gst with USE_YV12_SHADER defined, YV12 decoding will be handled by the graphics card, using a single rgb texture. Note that this shader is completely untuned, however, and very experimental.

The win here is that not only are you offloading a lot of work from the CPU (most videos tend to be stored in YV12 format), but you’re also halving the texture upload (YV12 has quarter-resolution chroma). I imagine I’ll get back to this after guadec and implement it in the correct way. Patches welcome of course.