digital home of MacSlow

I just forward the information Quim “Making It Happen” Gil put on the guadec site to p.g.o here. You can get from the bus-station (the one right in front of the train-station) to Barcelona airport at these times:

Friday…

• 14:30
• 15:30
• 16:30
• 17:30
• 18:30
• 19:30
• 20:30
• 21:30
• 22:30

Saturday…

• 7:00
• 9:00
• 11:30
• 13:30
• 16:30
• 18:30
• 20:30

The ride with the bus will take about an hour and certainly cost under € 4,-.

OMG, was Guadec cool! I just plain love you all folks! I’ll blog about my impressions when I’m back home.

Strike, I’m here (writing this via the guadec-wifi-spots) and already met people like Carl Worth, Josh Kress and Aaron Bockover. Nice! Jeff, Sebastien and Daniel… bungalow (btw it’s 348) in the guadec-village is claimed and beds are made (kind of :). When will you folks hit Vilanova approximately? I’ve one key for it. I’m not sure if there are more. So when you hit Vilanova, just be sure to get from the train-station to the UPC (just 2 min. by foot from the train-station). I’ll be around the whole day helping out a bit. I’m running around in typical capoeira-outfit (but with a brown ubuntu t-shirt). We’ll run into each other.

It’s nice to read Bryan’s words about his first encounter with the magnificent brazilian martial-art: capoeira. Bryan, let me tell you, this initial ardour you witnessed does never wear off again. I started almost six years ago, training with the group “Oficina da Capoeira”. I hope to get a few moments of beach-time during guadec and practise some combos and acrobatics. Should there be any other capoeiristas among the guadec attendees, please drop me a line so we may be able to arrange a little roda or something. Capoeira is something once started you cannot stop again ever! It’s very addictive, full of energy and expressive… much like OpenSource.

It looks like I’m up against some really tough competition (manpower- and/or cash-wise) with lowfat. There’s the multi-touch interaction research project by people of New York University’s Media Research Lab. That project already made some news a few months ago. Of more recent date is the project called BumpTop by people from the University of Toronto. While both of these projects target slightly different (from lowfat) goals and do not seem to strive for platform-independence, I still regard them as my “closest competition”. I love the multi-pointer interaction of the first one and like the approach of mouse-gestures in the second one.
Sort of related to my interests and plans for lowfat I found out about MPX (a multi-pointer X11 Server). That’s something I would like to be able to investigate at some point. Preferably on a tablet-PC with a spiffy OpenGL-chip and a well-accommodated Linux. Could this be a start of a multi-pointer extension for X11? I would definitely welcome such an outcome!
Damn, where are the lowfat-interested and filthyly rich VC-investors when you need them? Ah yeah right, I live in the wrong country for this… Germany here? *sigh*

Karl sent me an improved version, which further streamlines the placement-code. I added an animated background and shaped-input also. But it turned out that shaped-input is to costly to be updated with every redraw using the same rendering code. Doing an approximation with bounding-boxes is better suited. Furthermore Karl reported, that he experiences some major memory-leaking when using glitz under Xgl/compiz and a corruption of the text-labels. I’m able reproduce this too. Nasty! But not using glitz and everything is ok again. In contrast: using plain Xorg and xcompmgr those glitz-related issues do not arise. Hm. However the preformance leaves much to be desired if the CPU is under a heavy load (e.g. compiling), no matter if using glitz or not. Eye-candy clips for the day:

huge (click to play back, ogg/theora, ~2 MBytes)

the same, a bit smaller (click to play back, ogg/theora, ~1.2 MBytes)

I feel like a rewrite. The code grows messy and one starts to see that it all began as “quick&dirty”. I’ll try to revamp everything in a clean fashion until guadec.

Phew, what a ride the last 5 days have been! While working on the cairo-dock code some more, I got an eMail from Karl Lattimer asking if he can take over my code, once I’ve done my experimenting, to make a full dock-like application out of it. I surely welcome this! Furthermore he suggested to get in touch with Alex Graveley (main developer behind gimmie), beause the project wants/needs some cairo-love. Oh and Karl already registered and setup a site for his planned effort. See…

http://www.gnome-dock.org

I then did get in contact with Alex pointing him to the cairo-dock experiment, which happended with some funky timing, as Alex was about to email me about it *g* Then I got a first tweaked version from Behdad Esfahbod tuneing icon-placement, event-throttleing and font-rendering. I merged that with my stuff. In the mean time David Turner, who just recently wrote some great patches for cairo, xft and freetype beautifying subpixel font-rendering, writes on on the cairo mailing-list about some profiling he did with the cairo-dock code resulting some some optimizing patches for cairo. Those patches were happily accepted by Carl Worth, main master behind cairo itself. And if this wasn’t enough David Reveman, whom everybody should know by now from glitz/Xgl/compiz, sent me a patched version of cairo-dock adding glitz- and benchmarking support. Merged that too. Somewhere in between Jono Bacon does some pimping for me and - like Alex - wonders why I don’t show up at Guadec. Well, the main reason is the lack of cash. I’ll already burn everything in spare for going to LUGradio Live. I didn’t ever consider going to Guadec because it is too big/serious/over-my-head. Or put in another way… LUGRadio seems less intimidating to me. So the two poke me to at least try to ask Qium Gil if I can get in somehow. It turns out Qium also would like to see me hit Guadec. Sadly he has to turn my request for sponsorship down. Which I can surely understand. But I got flights covered via other means now and only need some place to sleep. Anybody got some square-feet free in their bungalows for a sleeping-sofa?

Guess what, I’m not done yet. Kristian “krh” Hoegsberg, chief of the wobbly windows among other things, pointed me towards some cairo-dock derived experiments he did with his new akamaru-engine. Check out the resulting dock binary after you compiled the stuff, which can be obtained there (Kristian just told me, that this tarball gets automatically regenerated as soon as he pushes changes to his repository):

people.freedesktop.org/~krh/akamaru.tar.gz

And just a couple of minutes ago Behdad told me on IRC, that he also did the same thing, merging code-stuff with David Reveman’s bits and pieces and asked for my latest version *sigh* I deeply regret to still not have setup my own public (git-) repository at people.freedesktop.org/~macslow. This would have made all this much easier.

Hot damn… what a ride sofar! OpenSource rocks plain hard!!! If you ever need a vivid and current example at OpenSource-magic at work. This is it *g*

Oh, I bet you want to see a current screencast and some code. No problem…

crisp and fast (click to play back, ogg/theora, ~2.5 MBytes)

BTW, that’s the first screencast, where I tried to record 20 fps with gvidcap and it did not crash on me *Strike*!

Some current code. You’ll need glitz-enabled cairo 1.1.6 for this. Also running under a composited environment (Xgl/compiz, xcompmgr, AIGLX etc.) would be nice. I’ve only tested this with plain Xorg/xcompmgr and Xgl/compiz under Gnome 2.14.1. Your mileage may vary, if you are running KDE, XFCE or else. The fastest and best looking way to start cairo-dock is to use this command:

./cairo-dock —glitz —surface-buffering

A word of caution though. I see rendering-artefacts when using —glitz in combination with —surface-buffering. I should try this with glitz from CVS-head maybe. Also be sure to checkout the —benchmark option, to see how fast cairo-dock can go without any throttleing (this will hammer your CPU of course). I get about 400-500 fps that way. If I disable the rendering of the text-labels, which are not surface-buffered, I get something around 1700 fps. Also check the cairo-mailinglist for some benchmarks David Reveman did, using a more current and tuned version of Xgl (improved server-side gradients and software-scaleing).

I hope this will start to make an end to complains about cairo and related libraries to be slow. They way it presents itself now is cool already. Just some code-example used to learn and better understand cairo/glitz/librsvg was enough to bring performance-tuneing and profiling to the surface (more public awareness) again. The main developers behind those mentioned libraries (btw, Dominic Lachowicz also did his part on working out some tuneing inside librsvg in those magical 5 days) know for sure what they are doing and have the right ideas what to optimize and how. But they need help and feedback… and no trolling. For example I picked up some discussion from Carl Worth and David Turner sparked by my questions on the mailing-list. They identified some “low hanging fruit”-optimizations. Carl will also do some major work on the cairo-core for tuneing the tesselator over the summer. David Turner will look into this too, if I recall correctly. I never want to hear that “it’s too slow”-crap again. Those “moaners” should better stand up and get their hands dirty, write some code, try out stuff, ask questions, look for help etc. Just don’t be lazy and help to make that difference now!

To Karl Lattimer: While I still have to setup (learn) git at people.freedesktop.org/~macslow (I’ll also finally put the official cairo-clock repository there) Behdad is about to put the most recent code for cairo-dock in his git-tree (that’s at people.freedesktop.org/~behdad/cairo-dock.git I believe). So Karl, I’d suggest you’ll grab stuff from there, and inject it in the svn-repo at www.gnome-dock.org to jumpstart the beginnings of gnome-dock.

… and still some heavy brain-fuckage on my side. I looked at all sugguestions people made after my blog-entry form yesterday. This is a list of things I’ve done sofar:

• use GDK_POINTER_MOTION_HINT_MASK
• use surface-buffering (only one per SVG-icon atm, thus scaled up icons look like crap right now)
• added a fps- and event-counter
• improved text-label rendering slightly, no so much shivering anymore
• started to enhance the icon-positioning
• tried to make text read better on different backgrounds
• enter/leave-notify-events for setting/resetting scales

The pointer towards the hint of repaint-throttleing from Federico somehow wasn’t of any use. I tired the provided example sourcecodes, but they made absolutely no difference in runtime-performance on my machine. So I left this issue aside for now.

If you’re keen on the current code. Grab the snapshot here. To make it clear, this isn’t utilizing glitz at all at the moment. I totally messed this up, due to wrong assumptions. What would I do without the helpful souls on #cairo like cworth and vlad

This is what is still missing (what I still want to try out):

• actually use glitz-surfaces and not only think they are used (that’s where my major brain-fuckage is/was)
• input-shape support
• further perfecting icon-positioning
• the typical mipmap-pyramid of scale-levels

Furthermore there seems to be someone interested to pick up my “cairo-dock” experiment and make a full project out of it. More details and facts on this at a later date.

I wanted to see how brutal I can be to glitz, cairo and librsvg by not using any buffering via image-surfaces rendering everything straight as svg. This is the example and its sysprof-log. I make this available for the sake of putting out a small but heavy test-case for the cairo-hackers (or the developers behind librsvg). It opens a transparent and decoration-less window and renders 11 svg-icons. Moving the mouse-pointer over them causes a OSX-dock-like effect, where the icon under the pointer gets scaled up and a title blends in above it. All other icons are rearranged accordingly. Each svg-icon is transformed using a cairo-matrix and finally rendered via librsvg. The scaling is triggered by the mouse-motion-event. While I expected this to be a bit of work for the CPU/GPU (using glitz-enabled cairo 1.1.6 here), I never thought it would max out that much. I’m running on an Athlon64 3700+ alongside a GeForce 6600 under Xgl/compiz. Why does this turn out to be such a burden for the CPU? Where’s the bottleneck? I hope someone can point out to me what’s wrong.

just the rects, fast (click to play back, ogg/theora, ~270 KBytes)

full svg-glory, dog-slow (click to play back, ogg/theora, ~600 KBytes)

ATTENTION… it is highly unlikely that I will make a full dock-like application for gnome (or plain gtk+) out of this. This time I will stay strong and resist any forces that attempt to lure me into doing this. It happend with cairo-clock. But not this time *g*. Of course it does by no means prohibit anybody else to pick it up and do so.