Re: The best/standard way to use opengl in gtk

[Jin Huang <hj cad zju edu cn>]

Thank you all for so many useful discussing.

It seems I have two choices.  One is gtkglext, and another one is clutter.

I use osg as the scenegraph, so it seems that a simple OpenGL windows 
with *configurable* (RGB or RGBA, double buffer or single buffer, etc.) 
OpenGL setting is enough. And I also want the program can be run in both 
Linux and windows system.  The major problem is that I have tried to 
compile gtkglext, but failed.  The link 
(http://www.bonifazi.eu/appunti/2008/02/gtk-glade-gtkglext-all-in-one-windows.html) 
which provides the pre-compiled binary has broken.

Clutter is very interesting, since it seems will be a "standard" way to 
use OpenGL in the future.  If so, that's great, and I am willing to try 
it.  Because I use osg, the performance may not be a problem, since 
clutter just providing a OpenGL rendering context. However I cannot find 
a simple example, e.g. call OpenGL routines to render a cube in side of 
the clutter, as the starting point.  Where can I get more information 
about this?

I love gtk, however, it is not so friendly to windows and OpenGL.

Best,

Jin

on 10/01/2010 01:03 AM, Emmanuele Bassi written:
> On Thu, 2010-09-30 at 16:08 +0100, Jeremy Henty wrote:
>
> > I would  *not* recommend using  clutter for 3D modeling  software.
>
> neither would I.
>
> >    At
> > work  I recently  had to  profile various  approaches to  GTK canvases
> > (gdk,  foocanvas,  goocanvas,  clutter,  gtkglext).  We  write  genome
> > browsers so we *have* to render thousands of items quickly.  I imagine
> > 3D modeling  software would have  similar constraints.  We gave  up on
> > clutter because of its performance.  Not only did it render slowly but
> > creating a new  clutter item was O(number of  already existing items).
>
> it's a scene graph: what did you expect? :-p
>
> granted, we're using the painters algorithm when we should be using more
> efficient ways of submitting geometry to the GPU - and we're working
> into implementing that[0], but at the end of the day any actor needs to
> be reachable through a graph.
>
> if you want to draw elements you might want to use a single actor and
> then use a VBO through the Cogl API - but, then again, you can use GL
> directly with GtkGLExt.
>
> it would make sense to use Clutter for the main modeling view if and
> only if the rest of the application UI was using Clutter.
>
> > GtkGlext was the only approach  that offered any hope of significantly
> > improving on good old foocanvas.
>
> clearly, since you need to drop down into raw GL, and that's all
> GtkGLExt provides.
>
> > Clutter seems to be focussed on eye-candy.
>
> "eye-candy" has generally negative connotations. Clutter is meant to be
> used to create compelling and dynamical user interfaces; it's an
> equivalent to CoreAnimation on Quartz and WPF on Win32. would you create
> a 3D modeling software using CALayers?
>
> > BTW, if  you profile  clutter then be  careful: for most  toolkits you
> > time the expose event handler, but in clutter that just sends an alert
> > to  a separate  clutter animation  event stream  and triggers  a paint
> > event handler.  Make sure you profile the right thing!
>
> on X11 you get an expose event for real windows; in Clutter, the only
> Window, as far as X11 is concerned, is the one implicitly created by a
> Stage. gtk+ 2.x too has moved away from sub-windows; and in 3.x gtk
> moves away from expose events delivered to widgets, in favour of a
> Clutter-like approach of top-down "draw" calls sent to each widget.
>
> ciao,
>   Emmanuele.
>
> [0] http://wiki.clutter-project.org/wiki/Cogl_Render_Lists