On Sat, 2008-04-05 at 20:23 +1300, John Stowers wrote:
Hey Guys,
I was wondering if any consensus was reached at the hackfest regarding a
canvas suitable for inclusion in Gtk+.
I tried to summarise the BoF we had at the hackfest here:
http://log.emmanuelebassi.net/archives/2008/03/berlin3/
in short, we identified two approaches:
- take one of the current canvases, give it the gtk+ seal of approval
and use the same approach used for cairo (if you want to use a canvas,
use this) with gtk+ providing the needed API for the developer;
- someone volunteers, takes one of the existing hardware accelerated
canvases and writes a completely new canvas straight inside gtk+.
+++
most of the points from Havoc's mail were agreed upon; since it mentions
Clutter, I'd like to address some of the points he has about it:
- Does not support multiple scene graphs in a single process,
inherits single global state from GL, but should be simple to
fix this
: we recently fixed this in trunk; you can now have as many top-level
containers (stages) as needed, which also means that you can have as
many GtkClutterEmbed widgets as you want inside your application. these
widgets do not work anymore using XEMBED, so writing new custom widgets
with Clutter handling the scenegraph and its animation is quite easy[0].
- COGL does some abstraction of GL details but does not
provide a context object, uses global state like plain GL
(COGL is Clutter's abstraction API for GL and GLES)
: this too has been changed (in a separate branch) and it's going to
land in Clutter trunk pretty soon, now. COGL has now its own state and
provides a nice wrapper around GL and GLES APIs, with texture loading
and drawing of primitives.
+++
one of the points raised in the BoF was the dependency on OpenGL for
hardware acceleration. not everyone has the hardware supporting it, it's
true, even though things are changing pretty fast in this area (the
Intel drivers are getting a lot of attentions with DRI2, ATi opened up
its spec, the nouveau OSS drivers are getting better on a daily basis,
and some day even nVidia will realise that releasing the specs will help
them as well). other toolkits and platforms have successfully been using
or providing support for GL-accelerated canvases for a while now, and in
the mobile arena GLES 1.1 and 2.0 are a reality that's here to stay in
every product currently in the design phase and that is going to hit the
markets in the next couple of years. do I think that gtk+ should
*depend* on OpenGL? no; but I think that gtk+ should use the currently
existing libraries to provide optional support for it where it's needed.
ciao,
Emmanuele.
+++
[0] one of the issues remaining is the current non-portability of the
GtkClutterEmbed widget on every platform supported by gtk+; Clutter does
have support for Quartz and WGL, and since we don't use XEMBED anymore,
Clutter backends for those platforms should be able to provide the same
way of passing a native window for Clutter to use to draw on. I'd really
like to ask to the Quartz and Windows gtk+ backends maintainers to give
a look at Clutter and help us.
--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
