digital home of MacSlow

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.

This is a follow up on “Messing around with the GPU and cairo”.

Since the sneak glimpse of my first steps with “cairo on the GPU” did not happen during the last plenary session at UDS last week (due to projector-synchronization issues), I present a screencast instead:

This is only spare-time work and nothing official (read: not my day-time job). So please don’t expect to be running inkscape all hardware-accelerated by next month or anything similar. Nevertheless, getting all of cairo’s rendering (compositing and rasterization) on the GPU, thus fully hardware-accelerating inkscape is one of my main motivations for doing this.

There are several approaches to solve this. One could map pixman/render semantics (”traps-only”) to the GPU in shader-code, implement the Loop/Blinn paper “Resolution Independent Curve Rendering using Programmable Graphics Hardware” or use the stencil-buffer method described in the OpenGL red book (p. 580). At the moment I am pursuing a combination of method 2 and 3 like MDK once did but never was able to make public.

The biggest problem to solve right now is high-quality anitaliasing along curve edges.

Just wanted to give big props to the Xorg-hackers (especially Kristian “krh” Hoegsberg) for DRI2 and the related bits, making redirected direct rendering (in layman terms: “GL under compiz”) on my i965 system a reality. I totally love that!

As promised the source to these examples…

(click for full size)

bzr branch http://bazaar.launchpad.net/~macslow/gtk-offscreen-1/trunk gtk-offscreen-1
bzr branch http://bazaar.launchpad.net/~macslow/gtk-gl-offscreen-1/trunk gtk-gl-offscreen-1
bzr branch http://bazaar.launchpad.net/~macslow/gtk-gl-offscreen-2/trunk gtk-gl-offscreen-2
bzr branch http://bazaar.launchpad.net/~macslow/gtk-gl-rgba-1/trunk gtk-gl-rgba-1

If you have gtk+ 2.12.x, libglade 2.6.x and gtkglext 1.0.6 and their respective development files installed, the not so usual…

./autogen.sh ; make

… in each directory will create the binaries. They all work under metacity, but usually look nicer under compiz.

This stuff is still very rough around the edges, so you will certainly run into one or more issues. But that last sentence probably nobody will ever read *sigh*

For those of you who where not able to come to FOSDEM and are interested in the eye-catching parts of my talk, I provide you with a screencast of the demo I hacked up to accompany my talk. This one is the second of the three demos (one, two, three) I showed in my talk to underline the facts I chatted about. To all trolls out there… this is about the effects and techniques used, not the content itself. So please spare me the “copycat”-reprovals.

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

(click to play back, avi/h.264, ~2.6 MBytes)

Here is something I wanted to show also (at least in video-form as it does currently not work on a i915 graphics-chip with current drivers) during my talk, but was not able to finish it up properly. You can clearly see the remaining glitches. Running on a GeForce 7900GT using nvidia’s proprietary driver. It provides a modest glimpse of what a future gtk+ might be able to do if it is fully composite-aware…

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

(click to play back, avi/h.264, ~2.0 MBytes)

All shown screencasts do not do the smoothness justice you see when running for real without the screen-recording going on. These kind of things will get much slicker once we have full EXA-accelerating drivers (paths for Copy, Solid and Composite) available in common distributions running on the latest and greatest X.org can/will provide. The screencast are all done under compiz.

BTW, the gtk+-developers are absolutely aware of missing features, shortcomings and expectations of users (both for end-users and for application developers). They have the drive and urge to improve and change things. So to the trolls… please just die! To everybody else… let go of everything and start helping out now. The more help they get form you, the faster we reach UI-toolkit heaven!

Any questions that might arise you may put in the comments-section or send me via email. And I have not forgotton about lowfat.

inkscape:
Just came across this. It is impressive to witness what kind of talents OpenSource-tools are able to attract these days. Have a look…

compiz:
Have you ever seen a recent build of compiz running? David Reveman implemented a fragment-shader based blur-plugin which allows clients (could also be done by a toolkit, e.g. gtk+) to define - via a X11-property (_COMPIZ_WM_WINDOW_BLUR) - which parts of a drawable (a whole window, just a widget or a part of the decoration) to blur. The blur is even opacity-dependent. To emphasize the last fact I slightly changed his provided blurdemo program and made a screenshot (note the change in the weight of blurriness from top to bottom in different parts of the window)…

blender:
New site, new version, new everything! Honestly it feels like I just truned away for a moment to look around, look back at blender and have the impression to see a completely new program infront of me. It is most remarkable what the team behind blender put together for the 2.43 release. Super sweet!

FOSDEM:
Finally I want to tout my talk I will be giving this sunday. Though I am not sure that I will be able to draw a large crowd or that I even want to draw a huge bunch of folks. Speaking isn’t something I feel really comfortable with (yet).

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)

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

(click to play back, avi/h.264, ~4.7 MBytes)

So, I hope you all had a merry christmas and will have supreme 2007… see you all next year!

From the “because we can”-department… comes this set of screencasts. The ogg-theora clip doesn’t fully show the nice blur in all it’s glory due to the compression. Try the avi-h.264 if you can for a more crisp view.

(click to play back, ogg/theora, ~970 KBytes)

(click to play back, avi/h.264, ~2.5 MBytes)

What you see is Ubuntu EdgyEft (therefore gnome 2.16), the new 1.0-9625 driver from nvidia (finally with native support for GLX_texture_from_pixmap) and the compiz-fork beryl. While the fragment-program based gaussian blur (using a 21×21 kernel btw) from the blurfx-plugin is not a productivity enhancer in any way (more a shameless mimicking of Vista’s areo-glass) it is a clear indicator that OpenSource is once more able to beat the proprietary solutions at their “own game”.

Watch this.

This is going to be a very long entry… I promise you… and I wonder how much flak I’ll get for this.

The recent months have clearly demonstrated that the average user of an OpenSource-system enjoys a healthy amount of bling. Just every computer-user is “guilty” of this. Some to a larger degree, some to a lesser one. The current state of things looks actually pretty good on our side of the fence… at least as long as inter-window effects are concerned (think: all effects made available via compositing-managers like compiz). Several effects are really improving usability or general accessibility (e.g. cube, expose-like scale, tab-switcher, unfold, desktop-zoom) and then there are some just for fun (e.g. wobbly, skydome). But sadly it stops here.

Those afore mentioned “inter-window” effects are just one part of the equation. The other paramount portion is made up of application-level or UI-toolkit-level effects. No idea what I mean? Some (admittedly) extreme examples:

• pulsing buttons
• smooth fading transitions or animated movement hiding or unhiding widgets or areas
• smoothly scaling up or down widgets or other UI-toolkit-level elements
• what about “cleanly animate and flip-rotate these video-texture surfaces from here to there”
• a consistent appeal and look between inter-window- and toolkit-level effects
• seamless integration of realtime-3D, 2D-vector-graphics, video and UI-elements in one application
• parameterized animation clues in the UI based on user-input, application- or system-state
• a reflecting, HDR-lit, shadow-casting map-view of your local area based on time of day and geographical position
• …

I could continue growing this list for some time. Just look at the UI of OS X Leopard (CoreImage, CoreVideo, CoreAnimation). Also Vista is well armed in that domain (Avalon aka Windows Presentation Foundation aka .NET 3.0 aka Windows Live Something). Now I can imagine some of you thinking: “Good lord… I get it. MacSlow wants to mimick the competition. What a faggot!” I’m sorry for you if you actually do think that. But that’s not the real deal behind it. We have most (if not all) of the needed low-level parts in place for this… cairo, OpenGL, gstreamer, librsvg, gegl (ok, not all are fully developed yet, but most are) to name some more well-known ones… akamaru, libclutter to name some lesser-known ones. What is needed is a general effects-, animation- and layout-library pulling together all those assests we have in the OpenSource field and become the icing on the cake in form of a convenience-layer. Also providing solid frameworks and standard boilerplate-calls for the usage of fragment/vertex-shaders, realtime image/video-filters etc.

That in turn should be used to conceive tools offering artists and designers to build UIs in a much more sophisticated fashion. Just like today design of an UI can be done in glade without a single line of code thus concentrating more on usability-aspects during the process. I would like to see people like e.g. jimmac not doing mockups of his ideas in blender, but for real and being able to test them out on real users… without him needing either learn all about coding gtk+, OpenGL, cairo and what not or waiting for some OpenSource-developer to find time and motivation to implement it. Or have the folks working on defining and testing the specs for Tango broaden their reach and also work on a common set of reasonable animation behaviours of a desktop UI. Things like those make all the sense (once we have the needed frameworks and tools in place). In my opinion this is something very worthwhile to undertake for Gnome & Co and the free desktop-systems in general. It does not stop on simple UI-matters. Having a standard set of shader-based effects for image-, video-, audio- and mesh-data provided by a common cross-platform library, makes the platform more attractive to developers, who are usually not very keen about Linux as a development-target at the moment. Aside from this, well-known OpenSource projects like Diva, PiTiVi, jashaka, jokosher et al. would probably also welcome such a tool set.

I would also like to see gtk+ 3.x, Qt 5.x, Gnome 3.x and KDE 5.x being able to base their future work on such a library. This would probably also be a welcomed effort by the Portland-project. Diversity is good… under the hood, but not on top, when you want to get things done. All Monos, Pythons, Rubys and whatever languages of the world will not give OpenSource-systems the boost in attracting new 3rd party developments, if we don’t boraden the disciplines our tool-chains can provide and simplify their utilization. This is especially of concern looking at the offerings on proprietary platforms. Big players like Sony, IBM, Sun, intel and should step in here to help with the heavy lifting ahead of us. The benefit for them is clearly a more media-complete solution with all the benefits OpenSource offers (I disregard the DRM-mess for the moment). Furthermore I would also like to suggest to the community to establish a good relation-ship with coders from the demo-scene. We need all the help we can get.

While this may not be needed today, it will be needed tomorrow and we better start working on it today to have it in a mature state in the future. No one can tell me that s/he would not like to see a project like this spawning. Of course it is a huge endevour… but to stop is to fall behind! It’s go big or go home!

Just my humble (but still very concerned and serious) 2/100 euro-cents. Comments welcome!

P.S.: These discussions here actually pushed the buttons in my brain to make me write up this.