On Sat, 2010-08-21 at 00:01 -0400, Havoc Pennington wrote: > On the Clutter front I'd still like to see the ClutterBackend > replaceable at runtime so you could basically put GTK in there or your > compositing manager in there, and avoid Clutter's attempts to do its > own Xlib things. That'd be a nice step forward.
one of the goals for 1.6 is to have a better Backend split between Clutter and COGL, since both have low-level interactions with the windowing system (e.g. COGL really needs to process events for handling the GLX_texture_pixmap and the GLX_swap_event extensions). one of the end results would be to have the windowing system part really generic and have extension points for init-time selection of the windowing system backend[0]. this would actually allow a GDK backend to be easily written; then clutter-gtk could depend on it, and embedding GTK widgets inside Clutter would be (relatively) easier than the current implementation - which is already possible anyway. another piece of the puzzle, and another step in the right direction, is to make a COGL backend for Cairo; this would allow high quality, hardware accelerated 2D rendering and avoid the current "render in an image surface and upload it to a GL texture" situation. the work to be able to make GTK render directly to a cairo_t* is, in this regard, necessary - especially for theme engines. the GtkSizeRequest interface in 2.90/3.0 is already making the Clutter and GTK+ size negotiation "match"; if we could manage to get a frame-based redraw cycle in GTK+, or to slave the GTK+ redraw cycle to the Clutter master clock, we could also use the animation API from Clutter directly into GTK+ itself. > All I'm saying is I think there's a useful direction to move in that > really doesn't require a huge rewrite. I generally agree, and I think that we can have a solid roadmap by the time of the hackfest to actually make this stuff happen during the 3.0 cycle. ciao, Emmanuele. +++ [0] Clutter obviously need to maintain its own backends, since it's actually also targeting platforms that are not GDK-capable (by design or requirement). it doesn't mean that a GDK backend could not be in-tree or be the default. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
