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