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 some of the items have already landed in trunk, we might be able > to squeeze in some other GPU-related feature, like exposing the GL > lighting API (see bug number: 1254). > > the release date for 1.0 depends on the stabilization process of the > features that are going to land in this cycle. hopefully, we'll be > able to keep up with the 5/6 months cycle we have followed until now > - so 0.9 should be out by December 2008 and 1.0 should be ready by > January/February 2009. > > after the 1.0 release, the API in Clutter core will be permanently > frozen for the 1.x series: only additions and deprecations will be > allowed, but no changes or removals. we obviously are going to add > features on the stable series, so you can expect a 1.2 and then a 1.4 > and then a 1.6 and possibly more. we also know that stagnation is an > issue, so we're going to branch fairly early for the 2.0 cycle > (ideally soon after 1.0) so that it will be possible to keep > experimenting without ruining the fun of application and integration > libraries developers. we don't have a release date for 2.0 yet, but > we expect the > 1.x API series to continue for at least a couple of years. > > ciao, > Emmanuele. > > -- > Emmanuele Bassi, Intel Open Source Technology Center
Emmanuele, Thanks for sharing the roadmap. and now I have some ideas for what clutter 1.0 would look like. :-) I also find some other features (e.g. bug1086 "virtualize stage_queue_redraw"; ) in bugzilla if I searched by setting Product as "Clutter" and the Target as "1.0". shall we implement or integrate them all in clutter1.0 either? btw: seems the bugzilla was also used for new features (change request) tracking system, right? :-) Elva -- To unsubscribe send a mail to [EMAIL PROTECTED]
