Re: gtk_widget_draw()

[Havoc Pennington <hp pobox com>]

Hi,

All of these changes sound really awesome.

On Sat, Aug 21, 2010 at 7:02 AM, Emmanuele Bassi <ebassi 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