Re: GTK + Clutter next step(s)

[Emmanuele Bassi <ebassi gmail com>]

hi Benjamin;

I generally agree with this plan. let me raise just a couple of
points...

On 2011-10-10 at 01:19, Benjamin Otte wrote:
> 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)

on this, we totally agree: clutter-gtk should be deprecated. Clutter's
multi-backend branch already has a GDK backend, courtesy of Giovanni
Campagna — along with the ability to compile multiple backends in the
same shared library. I already ported clutter-gtk to the Brave New World
of run-time selectable backends, with the exception of widget embedding.
I intend to merge the multi-backend branch into master this week, after
a review from Robert and Neil.

> - Provide the requirements to implement frame-based painting in GDK/GTK.

after thinking more about this point, and after the experience with the
GPeriodic experiment that Ryan wrote last year at the hackfest, I don't
think gtk needs a clock — I think that gtk should have the ability to be
driven by the Clutter master clock.

> - Allow GTK applications to use GL without hacks (read: no more
> GTKGLExt, less WebGL pain in webkit-gtk)

for this, I think a GdkGLWindow or a GtkGLDrawingArea would suffice;
multi-platform would be great, but without going to the extents of
wrapping the whole GL platform-specific API like GtkGLExt.

> - Have an actual point of data for the Cogl 2.0 API design. [2]

I'm sure Robert and Neil would like this very much. :-)

> - Make it possible for Clutter to get rid of its winsys layer and just
> use a GdkWindow.

again, the Clutter GDK backend basically already covers this.

> 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?

Cogl 2.0 is still experimental, but it's definitely the API that should
be targeted for toolkit development; Clutter internally uses the 2.0
API, and I'd expect gtk+ to do the same.

>   - 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?

Cogl's API stability guarantee for the 2.0 series is "we're not going to
break existing API during stable cycles, but we might during development
cycles"; the soname is bumped every time a breakage happens, so
distributions should be able to cope.

> - 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?

clutter-gtk really doesn't need much: it currently needs a way to set
the Stage window using a native handle, and that's it.

> - Add API to allow creating GdkWIndows for Cogl offscreens
>   - What do we (read: clutter-gtk) need here? Is GdkOffscreenWindow enough?

again, widget embedding doesn't require much: just a native handle for
an offscreen buffer that gtk can use to paint a widget in, and that
Clutter can use with the minimal (ideally: none) amount of copying
possible.

> - Port selected applications from clutter-gtk/GtkGLExt
>   - Which ones?
>   - Can we get the app authors to do this?

clutter-gtk apps that I know of:

  - sushi
  - cheese
  - gnome-documents
  - totem
  - empathy
  - eog-plugins (because of libchamplain)
  - gnome-games

> - Provide a way to switch Cairo drawing to GL
>   - We first need a cairo-gl/cairo-cogl to do this I guess?

cairo-cogl is coming along:

  http://cgit.freedesktop.org/~rib/cairo/log/?h=wip/cogl-backend

and I know that Chris Wilson is reviewing it.

>   - I want this to improve cairo-gl, are there other uses?
>   - Any requirements from the Pango side?

I guess a proper renderer using a GL glyph cache would be nice; our
cogl-pango renderer has served us well, but it can be improved.

thanks again for looking into this.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi