Re: OpenGL, GtkGlArea, GtkGLExt
- From: Carlos Pereira <jose carlos pereira ist utl pt>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: OpenGL, GtkGlArea, GtkGLExt
- Date: Wed, 05 Mar 2008 18:37:22 +0000
Jon Harrop wrote:
On Tuesday 04 March 2008 18:14:39 Behdad Esfahbod wrote:
On Tue, 2008-03-04 at 17:04 +0000, Carlos Pereira wrote:
2) change the name, for example to Gtkglarea 2.0*, the legitimate
sucessor to Gtkglarea 1 (the last version of Gtkglarea that I downloaded
last week is 1.99 and still comes with gtk_signal_connect and other Gtk
1.2* functions deprecated long ago)
No, gtkglarea is dead.
GlArea still has many users and is the defacto standard for some languages.
We don't want a new widget. We want being able
to render to widgets using OpenGL as an alternative to using cairo.
That is, the GtkGlExt approach.
I'm not sure who you are referring to as "we" but many people need little
beyond GlArea. I have no desire to create Gtk-compatible widgets. I only want
to render general graphics quickly and easily using OpenGL.
I believe this would make Gtk more appealing, particularly for
scientific/engineering/architecture applications.
Carlos
I am a scientist writing software for scientists and engineers using Gtk from
OCaml via the LablGTK2 bindings. There are OCaml bindings for GlArea but not
GlExt because GlExt is considered too complicated to be worth binding.
If anyone is interested in improving the situation for scientists and
engineers then I would recommend taking this into account: keep it simple to
bind.
Hi,
I just ported my app (more than 200,000 lines, totally independent and
unlimited number of OpenGL areas, sharing pre-compiled OpenGL lists,
etc.) last night from Gtkglarea to Gtkglext, so I am in a good position
to highlight the differences, from the user's point of view. What
follows is a manual of everything I had to change (I assume GTK 2.0 is
used, for example g_signal_connect instead of gtk_signal_connect):
1) in headers, replace this:
#include <gtkgl/gtkglarea.h>
by this:
#include <gtk/gtkgl.h>
2) in makefiles, replace this:
-lgtkgl
by this:
-lgtkglext-x11-1.0
3) in makefiles, replace this (distribution-dependent, Fedora 8 here):
-I/usr/include/gtkgl-2.0
by this:
-I/usr/include/gtkglext-1.0 -I/usr/lib64/gtkglext-1.0/include
4) in drawing code, replace this:
if (gtk_gl_area_make_current (GTK_GL_AREA (area)))
{
/* OpenGL here */
}
by these:
GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (area);
GdkGLContext *glcontext = gtk_widget_get_gl_context (area);
if (gdk_gl_drawable_gl_begin (gldrawable, glcontext))
{
/* OpenGL here */
gdk_gl_drawable_gl_end (gldrawable);
}
5) in starting code, replace this:
gdk_gl_query();
by this:
gtk_gl_init (&argc, &argv);
GdkGLContext *glcontext = NULL;
GdkGLDrawable *gldrawable = NULL;
6) in creating area code, replace this:
GtkWidget *area;
int attribute[] = { GDK_GL_RGBA, GDK_GL_DOUBLEBUFFER, GDK_GL_DEPTH_SIZE,
1, GDK_GL_NONE };
area = gtk_gl_area_share_new (attribute, (GtkGLArea *) area);
by this:
GtkWidget *area;
if (glconfig == NULL)
{
glconfig = gdk_gl_config_new_by_mode (GDK_GL_MODE_RGB |
GDK_GL_MODE_DEPTH | GDK_GL_MODE_DOUBLE);
if (glconfig == NULL)
{
glconfig = gdk_gl_config_new_by_mode (GDK_GL_MODE_RGB |
GDK_GL_MODE_DEPTH);
if (glconfig == NULL) exit (1);
}
}
area = gtk_drawing_area_new ();
gtk_widget_set_gl_capability (area, glconfig, glcontext, TRUE,
GDK_GL_RGBA_TYPE);
7) Initially, both glconfig and glcontext point to NULL. BEFORE the
first drawing area is created, glconfig is obtained, with a double- or
single-buffer, and used for all drawing areas. AFTER the first drawing
area is realized (shown), glcontext must be obtained, and reused for all
the other drawing areas, with this command (when creating the first
area, glcontext is NULL):
glcontext = gtk_widget_get_gl_context (area);
Usually, throughout the application, there is ONE glconfig and ONE
glcontext, even if there are unlimited, independent, OpenGL areas.
OpenGL pre-compiled lists are shared only if glcontext is the same.
Conceivably, users could have some areas sharing some lists (with one
glcontext) and other areas sharing other lists, (with a different
glcontext), but this not usual. Conceivably, users could also create
areas with different capabilities, for example with or without depth
buffer, using different glconfigs, but this is not usual.
This is ALL that is needed, to port applications from Gtkglarea to Gtkglext!
Gtkglext looks slightly more lower level and flexible than Gtkglarea,
closer to the (X) metal as they say, but for users differences are small
indeed...
Carlos
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]