Hi David > Many thanks for the very prompt and helpful reply. I'm really sorry for > my ignorance about this, but is there any documentation or do you have > any suggestions for how to approach implementing a target? You need to implement target-specific classes for configs, windows and contexts. Each is divided into an interface and implementation, which both inherit from their respective target-neutral base classes. The correct target is selected when creating a config. From that config, you can get a target-specific window (i.e., 'create_gl_window' in GdkGLConfigImplClass); and from the window, you can get a target-specific context (i.e., 'create_gl_context' in GdkGLWindowImplClass). > Are the > current targets equivalent to what can be found in the quartz, win32 and > x11 folders? Yes. The X11 and Win32 should be functional; even though GTK+'s Win32 support is minimal. The quartz target has never been converted to GTK+ 3. > I was thinking to convert the x11 code, but without understanding it > better this is turning out to be quite tricky. Does this sound like the > right approach? If so then I'm happy to persevere. Well, that mostly depends on you. ;) However, the X11 target can serve as a blue print for a new target. What's your platform and what's the native API of your platform? You mentioned LXDE? Has it already been converted to GTK+ 3? I'm asking because the old GtkGLExt 1.2 (for GTK+ 2) is de-facto unmaintained and probably not worth the effort. Also, if you're on X11, you don't have to write a new target, but extend the current X11 target by a new implementation. > The gdk code from the current version of GtkGLExt in the repository will > compile with the GLES headers/libraries, which I found encouraging, but > I'm guessing this is the easy part! There is not much GL-specific stuff in the source code (if any). Besides the internals, there needs to be a way of selecting the rendering API (GL, GLES, VG) and the API's version. I had a look at the EGL spec and several extensions to GLX. I'd say, all this could be handled by a set of config attributes. Best regards Thomas > Thanks again, > > David > > On 04/06/12 17:15, Thomas Zimmermann wrote: > > Hi David, > > > > There is currently no support for GLES in any version of gtkglext. > > > > For the version ported to GTK+ 3, you'd need to implement a new target > > for your device's API, or extend one of the existing targets. All in > > all, that's maybe a few thousand lines of code. It's not trivial, but > > not that complicated either. > > > > Best regards > > Thomas > > > > > > Am Montag, den 04.06.2012, 13:40 +0100 schrieb David Llewellyn-Jones: > >> Hi, > >> > >> I have an existing application that uses GtkGLExt for its OpenGL > >> rendering, and am hoping to port it to run on a device that only has > >> OpenGL ES (1.1 or 2.0) support. This would be running in something like > >> LXDE. > >> > >> Is there any way to make GtkGLExt work using only GLES? I'm afraid my > >> experience of the GtkGLExt code is very limited, but I'd be very > >> grateful for any advice on whether this would be a viable approach or if > >> there's an alternative solution that I've missed. > >> > >> Kind regards, > >> > >> David > > > > > > _______________________________________________ > > gtkglext-list mailing list > > gtkglext-list gnome org > > https://mail.gnome.org/mailman/listinfo/gtkglext-list > > -- GnuPG: http://tdz.users.sourceforge.net/tdz.asc Fingerprint: 16FF F599 82F8 E5AA 18C6 5220 D9DA D7D4 4EF1 DF08 jsapigen - A free glue-code generator for Mozilla SpiderMonkey. See http://jsapigen.sourceforge.net for more information.
Attachment:
signature.asc
Description: This is a digitally signed message part