Graphics frameworks seems to be slowly heading in two directions:
- A roughly PostScript style immediate mode API. By “immediate mode” I mean you issue commands like “move here, then draw a line to here, then create a path that goes here here and here, finally fill that path in”. Take a look at the Cairo API to see what I mean.
Apple (arguably NeXT) got there first with Display PostScript, but DPS was a total sewer and nobody uses it anymore. The main problem with Display PostScript was that PostScript was far more powerful than was really needed ….. in particular PS is a turing complete programming language. That meant you could do the equivalent of uploading arbitrary programs to the display server. Imagine if any program could load any shared libraries it wanted into the X server: at best, the feature would be used badly, at worst, it’d be abused for nefarious ends. So Apple now use Display PDF, which is a bit like Display PostScript except different. You draw graphics by rendering using PDF primitives. In the Tiger (10.4) release, Display PDF rendering isn’t hardware accelerated.
The Linux community got there next with the integration of Cairo into GTK+ 2.8, Mozilla, OpenOffice and other projects. Cairo isn’t much different to Display PDF in concept, but the API is cleaner and easier to use as it didn’t try and ram a square peg (Acrobat files) into a round hole (a simple drawing API). Cairo is, theoretically, hardware accelerated as it simply layers over XRENDER – unfortunately most drivers ignore the opportunity. The nVidia drivers support it but it’s off by default for stability reasons. The nVidia guys claim they can’t enable it until there’s a test suite, the X developers have sent mixed messages back about this over the years. On the other hand, making Cairo use Glitz and therefore OpenGL isn’t too hard, and then it really is hardware accelerated, using the 3D acceleration pipeline. On most cards this is and will always be better than using the 2D hardware acceleration, which is what most RENDER accelerated drivers use (as far as I know).
Microsoft will get there last, for a change. Well OK, technically they got there before the Linux community did with GDI+ but GDI+ was really quite a crappy implementation (for instance, not hardware accelerated at all, very slow, lacking in features etc) and this sort of add-on DLL had been floating around for ages. I’m interested mostly in fundamental changes in graphics architecture here, not throwaway DLLs, so we can ignore GDI+. I’m not sure what the immediate mode drawing API in Vista will be, but it’s probably going to be a thin layer on top of Direct3D.
So basically, every major OS is heading towards having an immediate mode drawing API for 2D graphics that is accelerated by the 3D engine on the GPU. Cairo is looking good, and follows in the footsteps of OpenGL: provide a cross-platform, easy to use, hardware accelerated API and the world will beat a path to your door.
- Some kind of graph-based retained mode API layered on top. By “retained mode” I mean you say “I want an object here, another object there, and I want the last object to animate” and after you set it up, the actual rendering commands are generated by the framework. Usually this API also handles animation, input event handling and so on. Often this is called a “canvas” and many apps implement them internally for themselves. Attempts at creating a re-usable canvas API litter the programming landscape, most crater dramatically.
Nonetheless, people keep trying, mostly because a generic canvas API is a very powerful tool in much the same way that a widget toolkit is powerful. Write it once, everybody saves time (in theory) and apps can become more consistent as a result. So far nobody seems to have got the balance between features and ease of use right yet.
One of the attempts at creating a useful canvas I’ve been looking at lately is Piccolo. This has been created by a team of developers that have been writing canvases since the early 90s, and they’ve been around the block a few times. The API and implementation, at first glance, seems almost too good to be true. They’ve clearly learnt their lesson: Piccolo is a direct evolution of Jazz, which apparently died the typical death-through-overengineering such frameworks often do. Whilst most of the capabilities are the same, the rewrite focussed almost entirely on API ease of use and implementation size/speed. Piccolo is an incredibly small 180kb, complete with utility libraries!
Piccolo comes in several flavours: Java, .NET, Compact .NET, and .NET with Direct3D. So far the .NET version interests me the most, it’s the one the Piccolo team use internally for most of their new work, and of course it means we can use Mono which is a generally more pleasant environment than Java is.
So where’s the catch? The catch, of course, is that the .NET version relies on Windows. Specifically, it delegates a lot of the meaty hard work to the System.Drawing API (which is a wrapper around GDI+). This is mostly implemented in Mono, save for a few parts, which aren’t. Usual story. Still, the Piccolo code seems very straightforward and porting it directly to use Cairo instead of System.Drawing doesn’t look too hard. By setting Cairo up to use Glitz, you’d achieve a similar setup to the Direct3D implementation whilst simultaneously opening up the possibility of mixing 3D and 2D rendering.
This sort of super easy to use canvas opens up new possibilities in user interface design. And of course it might be useful for autopackage too – right now some of the graphics in autopackage like the uninstall animation are quite hacky, slow, flaky etc. And of course not as pretty as they could be. Providing a new frontend that is based on Piccolo could let us get a lot closer to my original vision for the graphical frontend, which wasn’t much like what we have today (dreams never are, are they?) 
