Clutter 1.2

The discussion opened on API additions wanted for Clutter 1.2. Emmanuele listed the proposed new features on the chalk-board (which are all tagged in the bugzilla). Texture atlasing is a major new user-visible feature; this also brings a unified texture cache. Layout management is another feature programmers will want. Then, the floor was opened to other topics.

On the topic of input methods, Emmanuele is thinking of adding a modules plug-in architecture similar to the one used by GIO: API stubs that can be implemented in inherited classes. This would allow pretty much any functionality added via GtkModules to be reimplemented to ClutterModules.

There was a question about improving the performance with regard to only uploading changed sections of a texture: when the Evolution throbber is running, there's no reason to upload the entire window again. There's FBO-related (frame buffer objects) work on-going to make this more efficient and work correctly but there's no time line.

The VSync issue was raised: getting VSync to work correctly on top of a GL window manager on top of buggy hardware is a really hard problem to solve. LPC had a side-track in which this issue was discussed but those familiar with the discussion have the impression that the outcome (none of them were there) was not conclusive. The problem lies deep in the hardware drivers and sometimes the hardware itself.

A question was asked about the performance of glReadPixels. Currently, Clutter uses a back-buffer to paint every actor a different color, glreadpixels() is used on the coordinates of the click, and the actor that was clicked is determined via the color that returns. There are three on-going separate ideas about how to do this differently, more efficiently, or just generally come at it from a different direction entirely (for example, non-rectangular, masked click regions). Look for more on this in the future.

The rest of the discussion revolved around defining the boundary between GTK and Clutter and how to articulate that to developers. There was a lot of lively discussion about what applications are well suited to each environment and a third class of applications that use GTK as a wrapper for menus and then contain a window region where "awesome stuff happens" (Clutter embedded). There was some agreement—looking at Apple as an example—that having two toolkits which specifically target a different kind of application with full support from Gnome wouldn't necessarily be a bad thing. In fact, having a usability guide for each, API references and programming guides for each, and reusing code for each where possible could provide a rich, diverse platform where any type of application is possible—and they fit together.