-- There is a simpler way to achieve the same functionality as GtkGlExt, by using the 6 functions described, below. -- Instead of having an OpenGL Window, per se, rather have the 6 functions that can be called on a regular GTK window to control OpenGL -- This would be easier to maintain. For the MM version, just wrap the 6 functions as members of the GTK Window class. -- It does not make sense to force all OpenGL functionality through another layer e.g. Cairo.
This sounds like a viable option, especially since the GTK developers are obviously pressed for time to keep OpenGL support current. Perhaps, the development team will notice this thread and have some comments.
On 02/11/2014 04:37 PM, Carlos Pereira wrote:
Hi Norman, To bridge GTK and OpenGL we need the following six functions: 1) **gtk_area_query** a function that asks if OpenGL is available 2) **gtk_gl_area_create** a function that creates a OpenGL area from a Gtk drawing area. 3) **gtk_area_current** a function that sets the current OpenGL context 4) **gtk_gl_area_swap** a function that swaps OpenGL buffers 5) **gtk_gl_area_wait** a function that flushes previous OpenGL commands 6) **gtk_gl_area_remove** a function that frees memory and removes a OpenGL area.With these 6 functions, you can have an unlimited number of simultaneous OpenGL graphic areas, sharing pre-compiled lists, with all sorts of buffers and lights (exactly as with GtkGLExt).My own implementation of these 6 functions is here (only for X Window system!):http://www.gamgi.org/gamgi_gtk_area.c http://www.gamgi.org/gamgi_gtk_area.hand a diff -r for my package between: 1) using GtkGLExt and 2) using the 6 functions above is here:http://www.gamgi.org/diff_gamgi_src_gamgi_exp_srcIf you want to compare the actual code just compare these two source trees (I can help if someone cares): http://www.gamgi.org/gamgi-src-0.17-exp.tar.gz (the version with the 6 functions above) http://www.gamgi.org/gamgi-src-0.17.tar.gz (the version depending on GtkGlExt)It's true that my own version (154 lines of C code, including comments and white lines!) does not support Windows and MAC OS X but is pretty clear that the 6 functions above, properly done for all systems around, would be just a few hundred lines of code... that's all that is needed for GTK to support OpenGL... and after 15 years we are still waiting for this...We really don't need several thousands lines of code as in GtkGLExt (although it works just fine for me!), much less higher level toolkits such as clutter with new APIs around...What we need is a single file with these 6 functions inside, written in a more professional way, for all systems supported (X11 Wayland Windows Mac OS X), and included in the oficial GTK package...In 2010, I posted working examples to gtk-app-devel-list gnome org, as simple as possible, done with GtkGLExt and the 6 functions above, to show how simple it was to add OpenGL support to GTK. None replied...CarlosCarlos, I am not an OpenGL expert. I just wrote my first OpenGL code, based on the SigGraph video "An Introduction to OpenGL Progranmming". It uses a vertex and fragment shader to put put up an orientable cube on the screen. I ported this to Gtk2GlExtMM, and I don't see how GTK could be offering a better interface. From what I saw, GTK is offering a fully functional window, allowing for widgets, and an OpenGL region into which to write. I did not feel encumbered in any way, nor do I think the efficiency of the code was impeded. But, I have little experience in this field.How would GTK need to be upgraded to do OpenGL better? How would it be better?-- More efficient at run-time? -- More flexibility for the programmer? -- Allow a fuller OpenGL functionality?I am asking out of curiosity, and am not presuming to be arguing against what you have said.Thank you. On 02/11/2014 12:23 PM, Carlos Pereira wrote:gtk 3 does support OpenGL. With clutter and cogl you can integrate plain OpenGL into your application. Maybe it's not as smooth as as Qt's OpenGlI am sorry this is just not true. As far as I can see Gtk 3 does not support OpenGL. Like Gtk 2. Like Gtk 1.widget, but it is better to use than this abandoned GtkGlExt.This is so painfully obvious that it really hurts. Supporting OpenGL is not to build a new API, a new toolkit, a new software layer between user code and OpenGL (or even worse, to write a poor replacement for OpenGL).I have been in the Gtk developers list since 1999, every 5 years we come again to this issue, to no avail. After almost 15 years watching Gtk developers telling nonsense about OpenGL, I came to the conclusion that Gtk developers don't even understand the issue. It is mildly offensive to ask OpenGL programmers to throw away their optimized OpenGL code and replace it by some clutter API that translates to... OpenGL code!There are hundreds of books about OpenGL, please buy one and learn OpenGL before posting these ridiculous statements.All that is needed to bridge Gtk 2 and OpenGL under X11 are about 250 lines of C code. I know because I distribute two versions of my package, one uses GtkGLExt, the other uses my own code. If you are really serious about this, I can point you to these packages and explain in detail the relevant C code. And I am not even an expert, I came to this code reading all I could about this...We have been asking for 15 years to include something like these 250 lines of code, that is ALL that is needed to bridge GtK and OpenGL (some of this code is specific for the X Window System - for Wayland, Windows and Mac OS X you will need some slightly different code). Even these 250 lines, many are comments and space lines... This is so ridiculous...Carlos_______________________________________________ gtkglext-list mailing list gtkglext-list gnome org https://mail.gnome.org/mailman/listinfo/gtkglext-list
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature