Future of Pigment

Pigment, (especially Jerakeen) is great stuff. I have been involved in that for about five months now, and I am quite proud of being part of this. For instance, Elisa or my recent screencasts speak for themselves: Pigment rocks! Yet, Pigment could rock even more; here is why, and how...

The issues

As I said earlier, we are thinking of what Pigment 0.5 should look like. First, here is a list of things that suck in pigment 0.3, and need (heavy) rearchitecturing to be fixed:

• no real 3D support: we can't do rotations or efficiently apply a transformation on a group of drawables, we can't handle lighting, different cameras or camera movement.
• there is no support (at least not in C) to ease the application of a transformation to a given set of drawables. There is a basic "group" support in pigment-python, but it is slower than it should and limited.
• writing a rendering plug-in is too complicated. A lot of the stuff that is done in plug-ins could be factorised in the core. This is partly why we only have an OpenGL rendering plug-in in Pigment 0.3
• there is no programmatic way (there's only logging) to asynchronously retrieve errors, even though most pigment functions trigger asynchronous events.
• the animation system (which is done in python, but that is not an architectural issue, we could do it in C) is not synchronised with the rendering.
• it is impossible to build pigment without GStreamer because we use GstObjects everywhere.

The solution

The other day at lunch, a soon to be ex-colleague told us (as I remember it):

You can either be part of the solution, or you can be part of the precipitate.

Here, we don't want to precipitate things, so all of these solutions might not be in place in 0.5.0, though the whole project will be architectured with these in mind, so we can add them later in 0.5.x. Anyway, here is the list of solutions we've been thinking of:

• API separation: we will have two distinct APIs, though they will be mostly compatible:
  • a 2D API that will be the only one available when using a 2D rendering plug-in (such as DirectFB or SDL) and will probably be quite similar to pigment 0.3.x
  • and a 3D API that will allow to take full advantage of modern GPUs, using proper 3D rendering plug-ins (such as OpenGL, OpenGL ES, or maybe someday Direct3D, who knows?)
• Basic scene graph: be able to accumulate transformations, with each node rendered with the transformations and states set for itself and its parents.
• Revamping of the plug-in system, to minimise the amount of work needed to write a rendering plug-in.
• Have an asynchronous way to report errors. GStreamer seems to do that with a bus, that might be a good idea for us.
• Use PAF (an animation library) when it's here, integrate it so that it is synchronized with the rendering.
• Stop using GstObjects. We use them in 0.3.x for easy logging and for the floating references facilities they provide. I see three ways to do that:
  • Implement our own PgmObjects providing the same functionalities.
  • Use GstObjects when GStreamer is available, forget about logging when it isn't. That would only leave the floating reference stuff to reimplement.
  • Fork the GstObject stuff out of GStreamer into a separate library.

Bonus track

These are non-architectural stuff that we'd like to implement at some point, some of them might even make their way into 0.3.x:

• Support for compositing (masking, specific blending functions between drawables).
• Support for OpenGL ES, Loïc is actually already working on that for 0.3.
• Improvements in texts: right now, it is impossible to know how much space your text is going to take (or how much text you can fit in your drawable) or to scroll text; functionalities for this would be great.
• Big improvements in texts (3D plugins): instead of rendering text in CPU into a texture, we could render them as polygons, that would eliminate all the issues regarding "when should we regenerate the text texture?".
• Support for vectorial graphics rendering through cairo.
• Support for SVG (possibly through cairo as well).
• GStreamer source: we already have a sink, a "PgmViewportSource" could be something useful for many people.
• Support for 3D models.
• Many other countless details (see below).

Conclusion

Of course, these three lists may evolve a bit, but overall, that's what we plan for the 0.5.x series. Note that there's also a wiki page about this. Needless to say, pigment 0.5 is gonna be *awesome* and allow applications to go a big step forward in UI experience(*). That should happen quite soon too: our ideal goal is to have something working for GUADEC 2008, and in all case, we should have a quite complete 0.5 by the end of the year.

(*) Read: applications using pigment are gonna kick asses.

---

---

Published

Tags

• Boulot 20
• Geekeries 31
• General 48