Re: gtk_widget_draw()

[Emmanuele Bassi <ebassi gmail com>]

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