[clutter] clutter 1.0 roadmap - draft for the clutter mailing list
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
Re: [clutter] cogl_texture_rectangle reorders your texcoords?
On Tue, 2008-11-11 at 15:26 -0800, David Lock wrote: Does anyone know the specifics as to why cogl inverts your tex coords when theyre backward? Is that method of mirroring not supported on all hardware perhaps? This is discussed in bug #1057 [1]. The original reason it did this I think was to simplify the code for drawing sliced textures. However it should be possible for Clutter to keep the image flipped by swapping the vertex coords as well which is what the patch does. I will commit the patch later today so it should be fixed in the next release. - Neil [1] http://bugzilla.openedhand.com/show_bug.cgi?id=1057 -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] GtkClutterViewport
Are there any plans to have something similar to GtkClutterViewport but that can contain multiple actors - like embedding the stage in the viewport and applying a size limit? The limit of a single actor makes GtkClutterViewport reasonably useless.
Re: [clutter] GtkClutterViewport
On Thu, 2008-11-13 at 06:47 +1000, Saul Lethbridge wrote: Are there any plans to have something similar to GtkClutterViewport but that can contain multiple actors - like embedding the stage in the viewport and applying a size limit? The limit of a single actor makes GtkClutterViewport reasonably useless. I didn't try it, but you probably can have a ClutterGroup as the actor in GtkClutterViewport. Then you are free to add as many actors to that group. Try that, and let us know! :) -- Pierre-Luc Beaudoin signature.asc Description: This is a digitally signed message part
Re: [clutter] gnome-shell / mutter / ARB_texture_rectangle
On Thu, 2008-11-06 at 10:04 +, Matthew Allum wrote: Hi; On Wed, 2008-11-05 at 13:03 -0500, Owen Taylor wrote: I think making it usage explicit and contained like this is really the only way to go in we do bring back in support for ARB_texture_rectangle without a lot of complexity and other pain elsewhere. Re devel branch - I dont see why this could not end up in the stable branch of which we are already having to track pretty much with mutter. My initial expectation was that there would be significant code churn and API changes, but looking at it, the remove texture_rectangle support patch is a lot smaller than I expected and doesn't look to hard or intrusive to reintroduce. Right, it should hopefully be pretty strait forward - all Id request is that we then something like a cogl_enable_legacy_texture_rectangle(boolean) which enables this old logic in texture creation and is well documented as to potential downsides it introduces into apps enabling it. Ewww. :-) I guess my feeling is that a cogl API addition is a cogl API addition, and that doing something entirely hacky doesn't make it less of an addition. To avoid API additions I first thought: - Could this be done entirely within cogl with an environment variable? Unfortunately no: the cogl_texture code doesn't have enough context to distinguish random textures from texture_from_pixmap textures, so the environment variable reading has to be done - Can it be done as a private clutter = cogl API in an not-installed header file? Unfortunately no: to do the multi-texturing that MutterShapedTexture uses to shape the window, the shape texture needs to be a texture_rectangle if the pixmap texture is a texture_rectangle. What about, in my patch, changing COGL_TEXTURE_ALLOW_RECTANGLE to COGL_TEXTURE_ALLOW_RECTANGLE COGL_TEXTURE_ALLOW_LEGACY_RECTANGLE and adding a scary warning like: GL_ARB_texture_rectangle rectangle has numerous limitations, including no repeats, and no mipmapping. It also requires incompatible texture coordinate in custom shaders. Future versions of Clutter will remove GL_ARB_texture_rectangle support entirely. ? But if you want to go with your approach, sure, I can do that. I'd need to also add: cogl_force_legacy_texture_rectangle(boolean), because there are cases where NPOT textures look like they are there but don't work properly. - Owen -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] gnome-shell / mutter / ARB_texture_rectangle
Hi; On Wed, 2008-11-12 at 17:04 -0500, Owen Taylor wrote: What about, in my patch, changing COGL_TEXTURE_ALLOW_RECTANGLE to COGL_TEXTURE_ALLOW_RECTANGLE COGL_TEXTURE_ALLOW_LEGACY_RECTANGLE and adding a scary warning like: GL_ARB_texture_rectangle rectangle has numerous limitations, including no repeats, and no mipmapping. It also requires incompatible texture coordinate in custom shaders. Future versions of Clutter will remove GL_ARB_texture_rectangle support entirely. Okey, so just to double check - you are saying no API additions to cogl nor clutter, just a magic env var which enables old behaviour in regards to texture_rectangle (and prints a nasty warning) ? == Matthew -- Matthew Allum, Intel Open Source Technology Center -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] gnome-shell / mutter / ARB_texture_rectangle
On Wed, 2008-11-12 at 23:51 +, Matthew Allum wrote: Hi; On Wed, 2008-11-12 at 17:04 -0500, Owen Taylor wrote: What about, in my patch, changing COGL_TEXTURE_ALLOW_RECTANGLE to COGL_TEXTURE_ALLOW_RECTANGLE COGL_TEXTURE_ALLOW_LEGACY_RECTANGLE and adding a scary warning like: GL_ARB_texture_rectangle rectangle has numerous limitations, including no repeats, and no mipmapping. It also requires incompatible texture coordinate in custom shaders. Future versions of Clutter will remove GL_ARB_texture_rectangle support entirely. Okey, so just to double check - you are saying no API additions to cogl nor clutter, just a magic env var which enables old behaviour in regards to texture_rectangle (and prints a nasty warning) ? No. I was proposing changing my previous patch (the one with the cumbersome cogl_texture_new_with_size_and_options()) to make the options scarier looking in name and docs. If I could just do an envvar, that would be great, but I can't figure out how to do that. - Owen -- To unsubscribe send a mail to [EMAIL PROTECTED]
[clutter] return value of gboolean type
Hi, Is it good to use gboolean as return type for query some bit masked propety? For example, clutter_actor_get_reactive return CLUTTER_ACTOR_IS_REACTIVE (actor), it is neither TRUE nor FALSE in glib 's definition. So there is a potential problem if people compare the return value of these functions to FALSE or TRUE in their condition expression. WEIKAI
