Re: GTK + Clutter next step(s)

[Benjamin Otte <otte gnome org>]

On Wed, Oct 12, 2011 at 12:43 PM, Robert Bragg <robert sixbynine org> wrote:
>> - Make sure all native GdkWindows are valid framebuffers for Cogl
>>  - Does that work today? What do we need to be careful about?
>
> One thing worth noting here is that we don't yet have proper OSX
> support in Cogl. Currently the OSX winsys support is still in Clutter
> and we use a dummy/nop winsys in Cogl. The plan is to add proper
> support to Cogl it just hasn't happened yet.
>
I'm not overly concerned about other backends. As long as we have a
clear path that enables those backends to work somehow (and broadway
is as scary as OS X here), I don't mind if nobody has walked that path
yet. After all, GTK 3 still doesn't work too well on anything but
Linux.

> Clutter internally explicitly builds on the unstable Cogl API and I
> think its best to avoid strong interface barriers between libraries if
> they aren't strictly needed since they can often simply stifle
> development. If we are going to move a lot of Clutter's winsys code
> into gdk I think it would be a shame if we loose the freedoms we
> currently get from having a slushy Cogl interface.
>
Yeah, I don't think I want to export cogl in any important public GTK
or GDK API - you should be able to build the same applications that
you build today without the need for Cogl or Clutter.
The place where it gets fuzzy and where we need to be careful is
writing widgets. How do we expect people (both us in GTK and external
coders like Webkit or Evolutions calender views) to create widgets in
our transitional period?

> If you were more concerned about churn and breakages with the 2.x API
> that you might have to deal with then I think here we just need to
> make sure we communicate well. We would aim to routinely test gdk
> ourselves to help avoid breakages, and help to keep gdk up to date
> with api changes. Gdk developers would need to follow the mailinglist
> to keep an eye on how Cogl is evolving too and make sure the design
> meets your requirements.
>
A problem here is that changes to the exported symbols might require
recompilations and so bumps and all these things that I have no real
clue about. I'm just afraid that "oh, your distro just needs to
rebuild everything that depends on GTK" scares people quite a bit more
than "rebuild everything depending on Clutter". But we'd better ask
someone with more clue about how distros handle these things.

> Personally I think it would quickly become unmanageable to allow
> widget authors to use use OpenGL directly except for a few special
> cases.
>
> As I mentioned earlier we have been considering offering a way to mix
> raw GL usage with Cogl (by allocating a separate context) but I think
> I would rather recommend that only be used for existing GL based games
> or e.g. for something like WebGL. If you want to use the GPU for
> actually rendering widgets its not going to work well at all if you
> end up with a separate GL context for each widget so I would
> definitely recommend using Cogl instead of GL for any widget where you
> expect more than just one in an application.
>
Yes, I definitely think that nobody should use OpenGL in the GTK world
unless he specifically tries to marry OpenGL based things with GTK
widgetry. I would be very scared of anybody having a glBegin() in
their widget's draw handler.
But I'm running into projects on a weekly basis that have GL
requirements and have no clue how they can achieve what they want with
GTK 3. And I certainly want to make that possible. I definitely don't
want to make it easy.

>> - Provide a way to switch Cairo drawing to GL
>>  - We first need a cairo-gl/cairo-cogl to do this I guess?
> I think cairo-gl would be quite difficult to integrate in a way that
> you can share the GL context if you want to use the Cogl API for
> drawing to widgets too.
>
> The problem with cairo-cogl though is that currently I'm only
> targeting mobile devices with a high dpi display and so I am
> specifically not aiming to match the antialiasing quality of the image
> backend (which cairo-gl does). I would need to do some extra work to
> support the same level of antialiasing but that should be doable.
>
I'm mostly interested in where Cairo developers should focus their
attention into speeding up Cairo. So far, this work seems to have gone
mostly into the image backend, and the xlib backend. But if we think
that in the future, GTK will likely use cairo-cogl, it seems like a
good idea to provide an easy way to test things with that backend, so
that when we finally switch the default rendering to that method, we
now it actually works.
I was thinking about having our env var GDK_RENDERING=cogl work (see
http://developer.gnome.org/gtk3/3.2/gtk-running.html for that). So in
that sense, I don't even mind if it produces inferior output today, as
long as it's easy to test with.

Benjamin