17.07.2007 OpenGL for Gdk/Gtk+

The idea of using OpenGL as a future core rendering architecture for Gtk+ has been brought up a couple times at GUADEC (and then some variations thereof). However there are good reasons to avoid that and major issues with the suggested approaches, in particular these need to be considered:

1) A dependency on OpenGL for a library as portable and as widely used as Gtk+ these days, could only ever be a weak one. That is, OpenGL features may or may not be used, depending on whether the current platform a Gtk+ application runs on actually has OpenGL available or not (e.g. by animating widgets conditionally to only be carried out when acceleration support is present).

2) The OpenGL 2D drawing API is effectively unusable for Gdk/Gtk+ drawing primitives. The main problem here is that OpenGL doesn’t provide pixel-perfect 2D drawing operations which are necessary for accurate input event processing and a coherent visual presentation (it also doesn’t always provide anti-aliasing in the 2D drawing API either). Here is a very good web page with nice screenshots summarizing the problems with OpenGL pixel-perfectness: OpenGL: “not pixel exact”, Hardware AntiAliasing.

3) By using XRENDER and hardware-accelerated X drivers, Cairo is already being performance optimized to utilize hardware acceleration. Trying to use a portable OpenGL subset instead (pixel shaders / triangle rendering) would be fairly pointless, it’d effectively be using the available portable hardware acceleration facilities through another indirection. So with more and more Gtk+-based platforms/applications moving to Cairo-based drawing, there is no additional infrastructure or support code needed to make use of available hardware acceleration facilities. Essentially, the portably usable hardware acceleration subset is brought to you automatically through Cairo and X.

For the lazy, here’s a quick overview of the artifacts presented on the OpenGL comparison page:

.

13.07.2007 Switch On Strings In C And C++

For Rapicorn i need a simple and nicely readable way to special case code on various strings, which isn’t a problem in most scripting languages but is not provided by C/C++. Switching on strings turns out to be a widely investigated topic: SOS (agay), TheScript, JavaBug (CNFW), CodeGuru, CLC-FAQ and google has lots more.

Now here goes my approach to switching on strings for C/C++, caveats upfront:
– The strings may only consist of identifier chars: [A-Za-z_0-9];
– Convenient application is based on a GNU Preprocessor feature: -imacros;
– Macro implementations use a GCC-ism: Statement Expressions;
– The convenient command line variant uses a bash-ism: Process Substitution;
– One compile-time script is needed, currently implemented in python (though it could be written in any language).

With this out of the way, let’s dive into the code. This is the syntax:

	switch (SOSID_LOOKUP (sample_string))
          {
          case SOSID (hello): printf ("Hello ");   break;
          case SOSID (world): printf ("World! ");  break;
          case 0: default:    printf ("unknown "); break;
          }

This is how the code needs to be compiled: gcc -Wall -O2 -imacros <(sosid.py <input.c) input.c

The actual implementation is fairly simple, sosid.py extracts all identifiers from SOSID() statements and generates a handful of macro definitions: SOSID(), SOSID_LOOKUP(), SOSID_LOOKUP_ICASE(), ... Plus input specific macros: SOSID__hello, SOSID__world, ... GCC will pick up those definitions via the -imacros option. That is enough to implement SOSID_LOOKUP() so that it can yield the integer IDs that the SOSID(*)/SOSID__* statements expand to for any string that corresponds to one of the SOSID(identifiers) occurring in the source file.

Example:
call_switch ("hello"); call_switch ("foo0815"); call_switch ("world");
Yields:
Hello unkown World!

The lookups are implemented via a binary search and the strings are sorted in a way so that binary searches for case sensitive and case insensitive lookups are both possible. That means for large string lists, the lookups which are of complexity O(ld N) actually have a performance advantage over lengthy if..else if..else constructs with O(N) complexity.
The code is available as a single script at the moment: sosid.py.

Note that the bash-ism, imacros-use and GCC-isms are not mandatory, ordinary temporary files can be generated by the script and be included instead and it could be adapted to generate portable inline functions. The identifier-chars restriction is a hard one though. It comes from the fact that SOSID(ident) must yield valid C/C++ integers, and that can only be accomplished by token pasting. Depending on GCC is good enough for Rapicorn, so people will have to express active interest in this, in order for me to make the script more portable.

29.06.2007 YummiYummiGit

Starting with the discontinuation of cogito, i began to wonder about my future git usage patterns. On the one hand, i have become quite used to the convenience of some of the cogito commands, on the other hand i found myself using or looking up git commands every other day. Since the discontinuation, cogito cannot be expected to remedy those work-flow interruptions any time soon, so i actually started to cook up my own small set of convenience wrappers. I’m adding those on demand whenever i need a new source repository command, and i try hard to keep it simple, avoid giving the wrappers any options and keep an eye on them being very shell-completion friendly.

The GPLv3 licensed result is a single shell script plus a handful links for invocation: yyhelp.

For the curious, the prefix ‘yy’ was chosen to allow conflict free shell completion. I’ll quote the yyhelp information here, so people can decide if it’s interesting for them and also get to see the installation instructions. I’m not entirely sure where to take this shallow wrapper in the future, however keeping it simple is really the main incentive behind it. Any deeper logic required should rather be filed as git-core requests. If you want to talk to me about YummiYummiGit, drop me a line via email, or try #git on irc.freenode.net:6667.

	YummiYummiGit                                                     YummiYummiGit

	NAME
		YummiYummiGit - The simplest git wrapper ever, yet convenient

	SYNOPSIS
		yyadd          [FILES...] - add files to git repository
		yybranch    [-f] <branch> - add branch (forcable)
		yybranchdel [-f] <branch> - delete branch (forcable)
		yyChangeLog               - show git log in ChangeLog style
		yycommit       [FILES...] - commit current working tree
		yydiff         [FILES...] - show committable differences in working tree
		yygc                      - repack and prune repository
		yyhelp                    - display yy* help information
		yylsbranches              - list branches
		yylstags                  - list tags
		yypull                    - pull upstream sources
		yypushpull                - push & pull upstream sources
		yyremove       [FILES...] - remove files from git repository
		yyreset                   - reset (revert to HEAD) all files in the tree
		yyrestore      [FILES...] - forcefully recheckout specific files
		yystatus                  - display working tree status
		yytag               <tag> - add tag
		yytagdel            <tag> - delete tag
		yyuncommit                - undo the last commit (must be unpushed)
		yyview                    - browse & navigate the history
		yywarp           <branch> - checkout new branch

	HISTORY
		YummiYummiGit was created as a very shallow wrapper around git-* tool
		option variants, to simplify common cases.
		Depending on programming habits, YummiYummiGit may or may not suit your
		daily needs. It is in any case not meant as a full replacement for the
		git interface (there is e.g. no yyclone) and subject to change.

	INSTALLATION
		To install YummiYummiGit, copy yyhelp into a bin/ directory from $PATH
		and invoke: ./yyhelp --create-aliases

	YummiYummiGit-0.4                                                 YummiYummiGit

28.06.2007 Searchable API Docs

Newly built GLib & Gtk+ API docs are online now. In the process, i fixed a long standing documentation feature request: searchable API docs. This turned out to be the most requested documentation feature at the GNOME booth LinuxTag 2007.

The documentation updates cover Gtk+-2.11.4, so they contain new features like: GtkBuildable, GtkBuilder, GtkScaleButton, GtkVolumeButton and GtkTooltip.

13.06.2007 Back Online

I just got back online after a full week of DSL-outage due to the Deutsche Telekom Strike. If you are awaiting response via email or bugzilla from me, please be patient, I’m doing my best to catch up. Feel free to poke me about urgent issues via IRC/IM though, or drop me a reminder if you haven’t heard back from me in another week.

04.06.2007 LinuxTag

As announced by Hallski, Sven, Mitch and me went to LinuxTag 2007 and operated the Imendio and GNOME booths. As usual, Sven did a great job nurturing random users approaching the booth, together with Mathias Hasselmann and Michael Köchling. I put more focus on the amazingly large program of the conference, of which I’ll give a short roundup here.

The Xen keynote was on Wednesday. Xen 3.0 comes with some interesting new features, it’ll introduce IO virtualization and supports new virtuallization technologies from Intel and AMD. One important lesson I took away from that session is that using virtualization aware drivers on the guest OS can boost performance from roughly 10% using generic virtualization techniques, to more than 90% of the ideal performance throughput (native host OS performance).

This day, there was also the ZODB3 talk. This is an object database which can be used completely independently from Zope, it provides a very nice interface in python to implement hierarchical object tree persistence, has ACID transactions with rollbacks and allows for doomed transactions. At the lower level it uses a stable subset of python’s pickle and supports multiple storage backends.

Thursday had a Linux forum where Thomas Gleixner discussed recent realtime work in the kernel. The low latency and preemption patches that went into the kernel over the 2.6.x series brought a number of positive side effects such as general responsiveness improvements on loaded systems and new debugging mechanisms. From the new debugging facilities and raised threading issue awareness amongst kernel developers, a good 1200 patches containing bug fixes and cleanups resulted. And development in this are has not come to a halt, current/future work includes getting rid of idle-state interrupts that do nothing by having a tick-less kernel that only wakes up every once in a while when actual work is due and cleaning up general jiffie dependent code in the kernel. Now what’s left to hope is that distributors get their act together and enable the low-latency preemption patches for their desktop kernels. The patches work, they are stable, and they provide a much better user experience. E.g. if you experience sluggish system behavior during crypto filesystem IO, or experience drop outs with your sound system/server, don’t blame it on the kernel people, blame it on your distribution not allowing time slice preemption.

The other talk I attended was held by Matthias Hopf about the Compiz+Beryl merger. The resulting effects he presented excited the crowd as usual, and then he talked some about ongoing developments like input event transformation. After the talk we had some more personal chatter about using the 32bit XRGB visual to add alpha channels to XWindows, and future X extensions to allow applications to notify the server about when to issue EXT_texture_from_pixmap (needed for flicker free composite support).

On Friday, Lennart gave a very good presentation on the state of PulseAudio. He described how it solves the vast majority of audio use cases and can in combination with libsydney finally put an end to the never-ending lack of a portable and usable audio API. Beyond the talk, Lennart and I used every spare minute during the LinuxTag days to discuss libsydneys new API. All in all, it looks like a suitable candidate to replace (or continue) the effort Stefan and I started with CSL (we later suspended the project assuming PortAudio would fulfil the role) to make sound backends transparent.

After lunch, Quim Gil presented present and future of the Maemo platform. The points I personally found most notable are:
* libhildon2 is going to become an upstream community project, using Gnome infrastructure like bugzilla, with Nokia providing the core developers.
* Future platform updates (applications and OS) should be possible via APT, so flashing becomes a secondary upgrade method.
* Nokia is currently collecting feature requests for the Maemo platform. They’ll be integrated into Nokias platform plans where possible, so if you have any input to provide, state it here: Maemo Roadmap Page.
* The Maemo versioning scheme now uses alphabetical letters to indicate versioning progress. The current/upcoming versions are:
– [B]ora: current platform (3.x);
– [C]hinook: next platform (4.x) based on Gtk+-2.10, comes with SDKs before launch;
– [D]iabolo: intended to keep API/ABI from here on, unless upstream also breaks;
– [E]lephanta: SBox2 might be available at this time.
* Nokia tries to open up as much of the Maemo platform as possible and they will try to reduce dependencies between opened software and closed platform components in the future. The reason that some programs stay closed anyway are: a) missing legal clearance or licensing for some code portions – opening up code in one division of the company might affect legal claims (IP) on closed components developed and supported in another division); b) code may be subject to hardware vendor NDAs.
* Nokia will embrace attempts such as getting Maemo to run on different hardware in the future, or running non-Maemo software on the N770/N800.
* Nokia intends to introduce abstraction layers for hardware specifics (N770 vs. N800 vs. future devices) where possible.

The closing talk for this day was the Gimp presentation by Simon Budig, titled “Pimp My Gimp”. Simon presenting new Gimp features has become somewhat of a LinuxTag tradition over the years, and as usual new Gimp features managed to excite the crowd, even though we also had the usual glitches like a perfectly tested new clone-tool refusing to work on stage. ;-)

Saturday morning started with a vivid presentation on DBus by Marcel Holtmann. Though no stunning new features were presented, he did a good job on introducing the overall architecture and getting the audience hooked up for DBus applications with his presentation and some simple example code.

After noon, there was a big podium discussion on preventive data mining of personalized records, currently planned to be realized in upcoming laws by the German government. While the forum was quite interesting and definitely necessary to have at a conference like this, the discussion didn’t present surprisingly new findings for anyone following matters already. The discussion was great however, mostly because of the strong involvement of a rather large audience. It was pointed out that there is a massive lack of public awareness for the incredible data mining hunger of the government organizations and certain big companies, and that this is one of the topics that are rather uneasy to educate the majority of the democratic republic on.

Later during the day, Jono Bacon gave his obligatory Ubuntu talk about how Ubuntu cares about user experience and about growing the community. Personally, I still feel that more involvement from Canonical in genuine upstream development such as e.g. the Gtk+ project would be better in the long run for both Canonical and the upstream eco systems.

Finally, there was the Open Source Press talk which started out on how CopyLeft used to be the natural state for information exchange since the beginning of mankind, until publishers came into existence in the 16th century and invented CopyRight restrictions to preserve their investments in terms of hardware and human resources. It then was suggested that in a completely networked future computer age, we’ll be back to a pure CopyLeft situation. The presenter didn’t really seem to apply his findings though, when in the second half of the session he assumed that all mass-digestible texts must be edited by publishers and thus unconditionally require copyright laws. He also didn’t want to acknowledge that books existed which are sold and published online or that large amounts of interesting text (>= 500 pages) could possibly be written by non-publishers. While this presentation showed that publishers do recognize and ponder about open content these days, it also made clear that they still have a lot to learn.

As a closing note, I’d like to say a big Thank You to the LinuxTag Orga-Team. All throughout the four days there was an exceptionally good program in five presentation rooms, with up to four additional forum presentations distributed across the booth areas. From our perspective overall event organization went pretty well, this also resonated in German media.

25.04.2007 Call For Help

Gtk+ Patch Testing & Committing:
Recently i was caught on IRC and asked to look into a few outstanding Gtk+ bug reports. Some of them easy, some of them not so easy, e.g. one required a lengthy in-depth evaluation of interacting code while some of the others already had patches applied. That particular moment, I barely had any spare time to look into Gtk+ bugs and was actually on my way to the shower and then head downtown. We still managed to squeeze in and close the bunch of 3 or 4 bug reports in less than an hour however, because people actually helped me in applying, compiling, testing and committing the changes. While core maintainer approval was a necessity for some resolutions, there was much more work to be put into each report beyond giving the OK to the final patch versions. In particular the patch applying, adaptions to recent trunk, compiling it, running the test suite or test cases and committing is something that many developers who are not overly familiar with the code base can still do. This is a great way to learn and get into a project, and to help out an understaffed core team. It is a great way to contribute to your pet project and will help to make your visions and ideas about it come true.

You can do this for Gtk+: Patch testing & committing

Gtk+ has a volunteer task list up on the wiki. One of the open positions is the one i just described, and it’d much help the project if people signed up for it. Note that having SVN access can help but is not a requirement for all tasks, access rights can be granted for active contributors.

Next time you wonder why your Gtk+ bug report seems stalled, don’t ask why it’s being processed so slowly, ask yourself why you’re not helping the project already, so all submissions can be processed faster, including yours. ;-)

13.04.2007 Gtk+ Volunteers

The Gtk+ project finally gets a structured way to absorb voluntary efforts. Here is my proposal for a Volunteer Task List on gtk-devel-list. The task list is currently being constructed in the Gnome Wiki: GTK+ Volunteer Tasks.

In other news, there’s been some discussion on width-for-height and height-for-width management around Gtk+ recently. So I summarized the approach taken by Rapicorn, which in a nutshell allows arbitrary constrains with multiple resizing iterations and employs dedicated strategies to stabilize the resizing process: Hysteresis problems in Gtk+Rapicorn size negotiation.

05.04.2007 Rapicorn Website

The generation rules for the Rapicorn website are now finally in place:

-> rapicorn.org <-

This should help to clear up some of the motivations behind the Rapicorn project, in particular how it relates to Gtk+ and why it aims at implementing features that are to some extend already covered by Gtk+ or other projects like GnomeCanvas.
Here is a small excerpt to wetten the appetite:

	These days Gtk+ is [...] a very successful toolkit.
	However, maintenance and continuous development of a project at this scope
	and scale come at significant costs in terms of development flexibility
	and compatibility. It is not anymore a suitable place for evolution of new
	experimental GUI technologies and quick paradigm shifts. So radically new
	toolkit approaches or design ideas now need to be explored elsewhere and
	only if successful and applicable can reflect back onto Gtk+ development.
	-
	Rapicorn explores some approaches which are simply different from
	established Gtk+ paradigms.

26.03.2006 Beasty Bits

I will quickly roll up some of the interesting bits that happened around Beast in the last couple of weeks.
Stefan Westerfeld sat down and put up a collection of the various instruments and loops he is producing with Beast. Nicely described BSE files along with Ogg previews are available in his music collection: STW Music Archive.

Hanno Behrens had been fairly active in pushing the Beast project before the last release. In particular he has been stirring up the mailing list with feature requests. One of the things we managed to get in in response to these efforts is a list of commonly used musical tuning systems. Besides the already supported 12-TET which is the 12 note per octave equal temperament used in all western contemporary music, this includes further TET variants, Indian tuning, pentatonic tunings, meantone tunings and various well tempered tunings mostly intended for organs.

Hanno also published a very well written C64-retrospective article about Beast synthesis in the 20th Issue (german) of the Lotek64 Magazine. And additionally, the technical backgrounds for this article are described in the Beast wiki: SID Vicious (english).

Bad Behavior has blocked 113 access attempts in the last 7 days.