Emmanuele Bassi wrote:
hi all;
as you might have noticed, work on Clutter trunk is progressing quite
nicely. obviously, the big question is: towards what? which features
will land in 1.0? will it be called 1.0? when will it be released?
what happens next? when do I get a pony?
well, it was more than one question. actually, those were a lot of
questions. apart from the pony one. that was just weird.
anyway.
let's try to answer some of those questions, shall we? the first
answer is: yes, the next stable release of Clutter will be called
1.0. we think it's time to hit the big 1: we feel confident about
the API, we feel confident about the feature set and we feel
confident that additional features can be added without breaking the
API/ABI contract we'll have in place for the whole duration of the
1.x API series.
here's the whole features list we are planning for 1.0; some of these
already hit trunk:
1. clean up COGL
the COGL API is still in a bit of a flux; we're trying to expose more
features of the GPUs without resorting to use GL/GLES all the time,
but this means dealing with a lot of cruft and dead ends we'd like to
remove from the API before it's sealed shut.
2. documentation
even though we have a near-100% API coverage in Clutter, some bits are
still missing or not explained. we also need a Cookbook-style
document, like the one I started for the Perl bindings.
3. better build
this means: single include file strategy for Clutter and COGL, unit
testing, removal of the circular dependency between COGL and Clutter.
all of this has landed in trunk in the past couple of weeks, with unit
testing getting in on last Friday thanks to Robert Bragg. to break the
circular dependency, COGL now has its own fixed-point type, to which
ClutterFixed maps transparently; and a Color type, which should be
completely opaque to the user (conversion functions are provided).
Clutter will still use the ClutterFixed and ClutterColor types and
API.
4. new tweening/simple animation API
this new API should replace the Effects API, hopefully with something
more powerful but flexible. the current approach is to use something
that looks a lot like the JavaScript tweening API. the bug number with
the implementation is: 1014.
5. unified text actor
this would remove the ClutterLabel and ClutterEntry actors in favour
of a generic Text actor, with the ability to be set editable on
demand. the separation between editable and non-editable actors is
mostly a style/theme issue, and thus should pertain to toolkits
written on top of Clutter; this actor would make text displaying and
text editing extremely easy for developers, who would then only care
about styling. the bug number with the implementation is: 1106
6. threaded glXSwapBuffer()
using a separate thread (if the application has threading enabled) to
swap the GL buffers on GLX. it has proven to be a performance gain,
but it still requires some testing. the bug number with the
implementation is: 1118
7. asynchronous images loading from disk
along with PBOs and some caching, this would minimize blocking when
loading an image from disk into a Texture. the bug number with the
implementation is: 1144
8. multitexturing support
this would be a COGL feature first, and if time permits, exposed
inside ClutterTexture API. the bug number with the implementation is:
1163
9. mesh API in COGL
already discussed on this list, landed in trunk.
10. disjoint paths and clip-to-path
a change in the semantics in the COGL path API that would make it more
Cairo-like, and allow non-rectangular shaped clip areas. the bug
number with the implementation is: 1172
11. promote the Pango renderer to public API
this has already landed in trunk, under the CoglPango namespace (to
avoid eventual namespace collisions).
12. backface culling
already landed, a simple function the toggles backface culling and
that should be used in the paint implementation of an actor.
13. include the ClutterCairo actor in Clutter core
since Clutter already depends on Cairo for the Pango renderer, we can
exploit the dependency to kill of the smallest of the integration
libraries. this is still on the undecided list of things because it
can be a performance hit for Clutter-based applications if the
application and toolkit developers are not careful when using cairo. I
already have a patch for this and will be attached to a bug shortly.
14. unify the linear and bspline path behaviours
instead of having two behaviours, a single behaviour capable of
switching between the two path modes - or even mixing them - would be
preferred. the bug number with the implementation is: 1252
15. move the repository to git
while technically not a feature, we're in the process of putting core,
all the integration libraries, bindings and toys into a set of git
repositories - split up, this time. :-)
since
