GTK + Clutter next step(s)

[Benjamin Otte <otte gnome org>]

After Emmanuele's mail[1] I've been wondering how to get there. In
particular, I've been wondering how to get there incrementally, so
that when we finally release a GTK 4.0, we can support a transition
that is as smooth for applications as the transition to GTK 3.0.

I think that the best first step in this task would be to integrate
Cogl into GDK. Here's the problems I'd like to solve with this
- Improve integration between Clutter and GTK (read: ideally make
clutter-gtk unnecessary)
- Provide the requirements to implement frame-based painting in GDK/GTK.
- Allow GTK applications to use GL without hacks (read: no more
GTKGLExt, less WebGL pain in webkit-gtk)
- Have an actual point of data for the Cogl 2.0 API design. [2]
- Make it possible for Clutter to get rid of its winsys layer and just
use a GdkWindow.
- Prove that people shouting "OMG, GL will make GTK slow" are stupid.
If we don't manage to solve all of this problems - or if we figure out
we can't solve all of them - I don't mind. I just want to know where
we want to go.

So how do I want to go about this? Here's a rough list:
- Make GTK build (optionally?) depend on Cogl
  - Should we try with Cogl 1.0 or go straight to Cogl 2.0?
- Make sure all native GdkWindows are valid framebuffers for Cogl
  - Does that work today? What do we need to be careful about?
  - How do other backends (in particular Broadway) do this?
- Introduce a gdk-cogl.pc for new APIs
  - What stability do we support here?
  - I'd say "no stability, use at own risk", but is that feasible?
  - What about major api changes to cogl?
  - How likely are distros to ship this?
- Add API to allow users of GdkWIndow to use Cogl
  - What do we (read: clutter-gtk) need here?
  - Can we have something like make_current() to get native GL drawing?
- Add API to allow creating GdkWIndows for Cogl offscreens
  - What do we (read: clutter-gtk) need here? Is GdkOffscreenWindow enough?
- Port selected applications from clutter-gtk/GtkGLExt
  - Which ones?
  - Can we get the app authors to do this?
- Get rid of clutter-gtk
  - Is anything missing at this point?
- Switch GTK to frame-based redrawing
  - Does that require API "changes" to GDK?
- Add functionality to GtkWidget for GL-based widgets
  - Can we use this to do more invasive changes?
  - Can we even change GTK's event model with this?
  - Can we get a simple API to do native GL drawing here?
  - If we can, should we?
- Provide a way to switch Cairo drawing to GL
  - We first need a cairo-gl/cairo-cogl to do this I guess?
  - I want this to improve cairo-gl, are there other uses?
  - Any requirements from the Pango side?

Note that all of these are incremental steps and they are possible to
do at any point in time, ie none of those steps must happen in the
same cycle as a previous step. Also note that we can at any point roll
back a step, rethink it, and redo it, as we don't export any new API
(apart from the experimental one that we don't give lots of guarantees
on). I think this is a rather important thing, because there is
probably nobody with enough of a clue on how the end result should
look. Certainly not me.

Comments?

Benjamin


1: http://mail.gnome.org/archives/gtk-devel-list/2011-August/msg00058.html
2: http://wiki.clutter-project.org/wiki/CoglDesign