Hi, All of these changes sound really awesome.
On Sat, Aug 21, 2010 at 7:02 AM, Emmanuele Bassi <eba...@gmail.com> wrote: > 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. Nice! > 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. Nice again! I think it's clear GL (via COGL) and not Cairo needs to be the "bottom" of the stock, though sadly for a while at least it's not practical to make this the default/mandatory. > 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. Oh yes indeed. (would love to see the master clock redraw loop sort of down in the GDK or COGL or somewhere layer) > [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. Exactly (and for GTK also, it will need a stack without GL in there for forseeable future for example). But I think there are natural abstraction points, that sort of make sense and clean things up _anyway_, that make everything play well together. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list