http://bonifazi.blogspot.com/2009/11/gtk-glade-gtkglext-all-in-one-windows.html
--
Marco Bonifazi
http://www.bonifazi.eu
On Fri, Oct 1, 2010 at 5:12 PM, Jin Huang <hj@xxxxxxxxxxxxxx> wrote:
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
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
--
Marco Bonifazi
http://www.bonifazi.eu
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
