The theoretical case for using the clutter framework in an actual game

I've been trying to wrap my mind around the clutter framework and the accompanying technologies for a while now, because it seems to be a powerful library that makes a lot of features easily accesible.

What might not be apparent, is that the problem it solves - the rendering of 2d graphics - is a problem in the first place. So let's examine for a moment what it actually is: A library that utilizes opengl as a backend for drawing hardware accelerated graphics.

Why is hardware acceleration necessary for a 2d game in this day and age? I hear you cry.
Well have a look at this:

http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D#Early_debate

Excerpt from the linked section:

"By 1998, even the much-maligned S3 Virge was substantially faster than the fastest Pentium II running Direct3D’s MMX rasterizer."

The S3 virge, presumably, was an elcrapo graphics card with 4 megabytes of VRAM, that might've cost about 40$ to slap into your run-of-the-mill prefabbed consumer desktop computer at Dell or HP. The fastest Pentium II, by comparison, must've been about 6-700$ or so, not even available in preassembled computers unless specifically requested.

The perspective this is meant to impress upon you is this: Hardware acceleration rocks, software emulation sucks, and this has been the case since 10 years ago, with the gap in performance/price widening every quarter ever since.

Ok, so we need hardware acceleration for the graphics. How do we get that?
We use a library. Libraries are collections of functional code that performs operations detailed in an API. A library is different from a system call in that a system call is implemented in the operating system, whereas the library resides in a little bubble attached to the operating system. Indeed, it "talks" to other libraries and hardware as directed and permitted by the operating system.

Even Direct X, which is microsofts multimedia library, is in a bubble attached to the operating system. While it's true that you cannot run windows without having some form of direct x on your system, direct x is a library because it does not belong within the windows kernel. As such, it's a library in it's own right. Microsoft also includes a version of openGL with Windows.

So why not simply use Direct X or OpenGL? Why use a library build on top of another library?
Because OpenGL, for example, is very simple. It only allows a program you write to communicate with graphical hardware through some very rigid functions.
Textures are a common concept within graphics rendering; it's a bitmap projected onto a geometric shape. But to OpenGL, a texture isn't a file on disk; it's a bitmap in memory. Converting a file on disk into a bitmap in memory is a function which OpenGL does not provide. So you need to either program it yourself, or find another library which can be used to read files into memory in a way that makes the final result compatible with OpenGL.

But Mads, you say, surely there are 2d libraries with hardware acceleration other than OpenGL and Direct3d, which are, after all, predominantly 3d libraries?

No, no there are not. Yes, there are 2d libraries, but no, they do not have hardware acceleration. Look at the firefox browser you're probably using to browse this blog right now. It uses the Cairo library. It's not hardware accelerated, and it shows. That's why web browsing is so processor intensive compared to how piss poor the graphics are. The responsiveness of the firefox webbrowser is _not_ good enough that the same kind of thing would go over well in a game.

So, clutter. It's a library that supports text rendering (which is a motherfucking bitch to implement yourself), textures (as in, you can load them from disc and manipulate them using an established framework), and fluid animations, all in an easy-access framework. It's also brand spanking new. And it's primarily a 2d rendering library, but perfect for working with many layers and grouped things because it has a scenegraph and a z axis thingie.

Sure, it's meant for designing interfaces, but that doesn't matter; if it's hardware accelerated, performance will probably be up to snuff. It even supports rendering of videos onto textures, and yes, this can be hardware accelerated as well.

About system requirements:
On ebay, for less than 200$, an eee pc 4g, the lowest performance eee, can be had. It's intel GMA900 graphics card can hardware accelerate opengl 1.4 - which is what clutter uses. Now seeing as intel owns openedhand, the developer behind the clutter library, this should hardly come as a suprise - the intel GMA 900 and above almost exclusively make up the graphics hardware in netbooks, and intel purchased openedhand with the intent of using clutter for rendering the UI on it's moblix platform....which is the operating system designed to push netbooks and mobile internet devices developed by intel.

Making clutter run well on the GMA900 and above, as a concequence, is likely a high priority at openedhand...

This implies that clutter will be a future-proof rendering option for a 2d game, and it also means that any 2d game written with it will likely perform well even on future mobile internet devices. Oh, and it's a cross platform library, of course, so games written with it run both on windows, linux and mac os x.

But if running on tiny, low performance netbooks isn't good enough, the first geforce graphics card to support opengl 1.4 is geforce 4, ti4600, which was the top of the line model back in febuary 2002. Every geforce model since 5xxx and forward has supported it as well. Same goes for every radeon including and above the 9500, which is also ca. 2002.

It's also likely that most laptops support it, though it's difficult to say because laptop gpu's are considerably worse documented; but anything both nVidea and ATI have been shovelling into laptops since 2004 ought to support clutter, and it's supported on _all_ of intels graphics hardware.

Finally, about licensing: Clutter, and all libraries it uses and works with, is released under LGPL. This means that it's legal to build proprietary software using the library, but that anyone who does so, ideally, allows people to upgrade to new versions of the libraries used if they want. I haven't figured out how difficult this aspect might be, yet, but I don't foresee any problems.