Nabble - Gnome - GtkGLExt

Re: OpenGL widget fills entire window on OS X [was: OS X Quartz developers...]

2009-11-25T18:01:31Z

I've read a bit more on the Next Step windowing system (a bit more). AAAhhhh if I only had the time.

You may be on the right track, which still points to the fact that you are deriving the object from NSView instead of NSOpenGLView. NSOpenGLView implements a lot mechanism that are required for Composer (part of the windowing system) to set it up correctly. It may be that in your imp the required initialization procedures are not being done, or the methods necessary to control the actual GL window itself are not there.

NSOpenGLView IS a NSView with addition initialization and implementation routines necessary for the GL window.

EMAILING FOR THE GREATER GOOD
Join me

> From: jacob@...
> Date: Wed, 25 Nov 2009 21:01:06 +0100
> To: gtkglext-list@...
> CC: shashaness@...
> Subject: Re: [GtkGLExt] OpenGL widget fills entire window on OS X [was: OS X Quartz developers...]
>
> On Nov 23, 2009, at 8:21 AM, Andrey Gruzdev wrote:
>
> > Hello.
> > The problem with non-OpenGL widgets takes place only with new GTK versions.
> > Then I wrote this patch and test it with gtk 2.14 beta framework build and some later builds (built with jhbuild script) this problem does not appear.
> > Unfortunately I have not free time now but I hope to get it soon and spend some for this project.
> > There are no Low Level API used in my patch. Only NSOpenglView, NSOpenglContext and some related functions.
>
> Could it be that NSOpenGL - View/Context, gets the wrong coordinates?
> I don't know windowing in Cocoa but I guess there is a hierarchy of NSView and that Context needs a NSRect from
> the gldrawable gtk widget?
>
> /Jacob
>
> > Andrey.
> >
> > On 22.11.2009, at 20:27, Jack Skellington wrote:
> >
> >> The problem seems to be that when rendering to the OpenGL capable
> >> widget it expands to fill the entire window.
> >> If I resize the window the gtk widgets are visible for a split second
> >> before they are covered with white background.
> >> But the OpenGL rendering works fine otherwise.
> >>
> >> This is my main rendering loop:
> >>
> >> gboolean G_MODULE_EXPORT render(gpointer data){
> >>
> >> GtkWidget *widget = GTK_WIDGET(data);
> >>
> >> GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
> >> GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);
> >>
> >> if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
> >> return FALSE;
> >>
> >>
> >> glClearColor (1.0, 1.0, 1.0, 1.0);
> >> glClearDepth (1.0);
> >> glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
> >>
> >> engineIteration();
> >>
> >> gdk_gl_drawable_swap_buffers (gldrawable);
> >>
> >> gdk_gl_drawable_gl_end (gldrawable);
> >>
> >> return TRUE;
> >> }
> >>
> >> Regards
> >> Jacob K
> >>
> >> On Sun, Nov 22, 2009 at 11:49 AM, Jacob Juul Kolding <jacob@...> wrote:
> >>> On Nov 21, 2009, at 6:30 AM, Braden McDaniel wrote:
> >>>
> >>> On Sat, 2009-11-21 at 02:33 +0100, Jack Skellington wrote:
> >>>
> >>> Hi all!
> >>>
> >>> I'm currently working on porting a commercial Gtk+ OpenGL App to Snow
> >>>
> >>> Leopard using the actively developed and maintained Gtk+ OS X Quartz
> >>>
> >>> backend. My last problem now is that GtkGlExt only works with X11. I'm
> >>>
> >>> not familiar with the Low Level OS X API's, so I'd properly wouldn't
> >>>
> >>> be able to write the backend myself but I think it would be awesome if
> >>>
> >>> someone here could help with the native OS X backend, getting closer
> >>>
> >>> to a fully supported native Gtk+ :)
> >>>
> >>> This patch is probably a good starting point:
> >>>
> >>> https://sourceforge.net/tracker/?func=detail&aid=2750584&group_id=54333&atid=473436
> >>>
> >>> I'll try to get back to reviewing this soon; though it might have to
> >>> wait until I get my KVM back from RMA.
> >>>
> >>> Do let me know how it goes for you.
> >>>
> >>> I managed to apply the patch and compile both GtkGLExt and my app, but when
> >>> I start my app
> >>> the main windows is complete empty of any gtk widgets (white background
> >>> everywhere), the only thing thats visible is the borders I draw in the
> >>> opengl area, but
> >>> when I move the mouse up the the invisible file menu I'm able to open other
> >>> (non opengl) windows which works as expected??
> >>> Regards
> >>> Jacob Kolding
> >>> dacobi@...
> >>>
> >>> --
> >>> Braden McDaniel <braden@...>
> >>>
> >>> _______________________________________________
> >>> gtkglext-list mailing list
> >>> gtkglext-list@...
> >>> http://mail.gnome.org/mailman/listinfo/gtkglext-list
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> >>> trial. Simplify your report design, integration and deployment - and focus
> >>> on
> >>> what you do best, core application coding. Discover what's new with
> >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> >>> _______________________________________________
> >>> Gtk-osx-users mailing list
> >>> Gtk-osx-users@...
> >>> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
> >>>
> >>>
> >> _______________________________________________
> >> gtkglext-list mailing list
> >> gtkglext-list@...
> >> http://mail.gnome.org/mailman/listinfo/gtkglext-list
> >
> > _______________________________________________
> > gtkglext-list mailing list
> > gtkglext-list@...
> > http://mail.gnome.org/mailman/listinfo/gtkglext-list
>

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: OpenGL widget fills entire window on OS X [was: OS X Quartz developers...]

2009-11-25T12:01:06Z

On Nov 23, 2009, at 8:21 AM, Andrey Gruzdev wrote:

> Hello.
> The problem with non-OpenGL widgets takes place only with new GTK versions.
> Then I wrote this patch and test it with gtk 2.14 beta framework build and some later builds (built with jhbuild script) this problem does not appear.
> Unfortunately I have not free time now but I hope to get it soon and spend some for this project.
> There are no Low Level API used in my patch. Only NSOpenglView, NSOpenglContext and some related functions.

Could it be that NSOpenGL - View/Context, gets the wrong coordinates?
I don't know windowing in Cocoa but I guess there is a hierarchy of NSView and that Context needs a NSRect from
the gldrawable gtk widget?

/Jacob

> Andrey.
>
> On 22.11.2009, at 20:27, Jack Skellington wrote:
>
>> The problem seems to be that when rendering to the OpenGL capable
>> widget it expands to fill the entire window.
>> If I resize the window the gtk widgets are visible for a split second
>> before they are covered with white background.
>> But the OpenGL rendering works fine otherwise.
>>
>> This is my main rendering loop:
>>
>> gboolean G_MODULE_EXPORT render(gpointer data){
>>
>> GtkWidget *widget = GTK_WIDGET(data);
>>
>> GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
>> GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);
>>
>> if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
>> return FALSE;
>>
>>
>> glClearColor (1.0, 1.0, 1.0, 1.0);
>> glClearDepth (1.0);
>> glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>>
>> engineIteration();
>>
>> gdk_gl_drawable_swap_buffers (gldrawable);
>>
>> gdk_gl_drawable_gl_end (gldrawable);
>>
>> return TRUE;
>> }
>>
>> Regards
>> Jacob K
>>
>> On Sun, Nov 22, 2009 at 11:49 AM, Jacob Juul Kolding <jacob@...> wrote:
>>> On Nov 21, 2009, at 6:30 AM, Braden McDaniel wrote:
>>>
>>> On Sat, 2009-11-21 at 02:33 +0100, Jack Skellington wrote:
>>>
>>> Hi all!
>>>
>>> I'm currently working on porting a commercial Gtk+ OpenGL App to Snow
>>>
>>> Leopard using the actively developed and maintained Gtk+ OS X Quartz
>>>
>>> backend. My last problem now is that GtkGlExt only works with X11. I'm
>>>
>>> not familiar with the Low Level OS X API's, so I'd properly wouldn't
>>>
>>> be able to write the backend myself but I think it would be awesome if
>>>
>>> someone here could help with the native OS X backend, getting closer
>>>
>>> to a fully supported native Gtk+ :)
>>>
>>> This patch is probably a good starting point:
>>>
>>> https://sourceforge.net/tracker/?func=detail&aid=2750584&group_id=54333&atid=473436
>>>
>>> I'll try to get back to reviewing this soon; though it might have to
>>> wait until I get my KVM back from RMA.
>>>
>>> Do let me know how it goes for you.
>>>
>>> I managed to apply the patch and compile both GtkGLExt and my app, but when
>>> I start my app
>>> the main windows is complete empty of any gtk widgets (white background
>>> everywhere), the only thing thats visible is the borders I draw in the
>>> opengl area, but
>>> when I move the mouse up the the invisible file menu I'm able to open other
>>> (non opengl) windows which works as expected??
>>> Regards
>>> Jacob Kolding
>>> dacobi@...
>>>
>>> --
>>> Braden McDaniel <braden@...>
>>>
>>> _______________________________________________
>>> gtkglext-list mailing list
>>> gtkglext-list@...
>>> http://mail.gnome.org/mailman/listinfo/gtkglext-list
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>>> trial. Simplify your report design, integration and deployment - and focus
>>> on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Gtk-osx-users mailing list
>>> Gtk-osx-users@...
>>> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
>>>
>>>
>> _______________________________________________
>> gtkglext-list mailing list
>> gtkglext-list@...
>> http://mail.gnome.org/mailman/listinfo/gtkglext-list
>
> _______________________________________________
> gtkglext-list mailing list
> gtkglext-list@...
> http://mail.gnome.org/mailman/listinfo/gtkglext-list

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

smime.p7s (2K) Download Attachment

Re: [Gtk-osx-users] OS X Quartz developers Call to Arms

2009-11-25T10:35:47Z

On Nov 23, 2009, at 5:35 PM, Shawn Bakhtiar wrote:

Cool... did not even know there was a list for gtkglext.

I actually have some need of this. Just don't have time to work it, not sure if I have the know how either.. I am swamped with other work.

I myself do not have a good grasp of the Next Step Windowing system, but it looks like the implementation uses the NSView (check in gdkglwindow-quartz.h) instead of the NSOpenGLView, which means (given the dates on the patch) that some of this needs to be changed before it will work.

I bet you if you just change these lines to use the new NSOpenGLView it may indeed work

gdk/quartz/gdkglcontext-quartz.c:294: NSView *quartzView; gdk/quartz/gdkglcontext-quartz.c:325: name: NSViewFrameDidChangeNotification gdk/quartz/gdkglwindow-quartz.c:127: NSView *quartzView; gdk/quartz/gdkglwindow-quartz.c:184: NSView *view = GDK_GL_WINDOW_IMPL_QUARTZ (draw)->quartzView; gdk/quartz/gdkglwindow-quartz.h:23: NSView *quartzView;

I've tried changing to NSOpenGLView, but it doesn't seem to have any effect.

My app behaves the same way after re-linking and

grep'ing the lib still shows only NSView and NSOpenGLContext. (this is after a completely clean patch/build/install)

Maybe it has something to do with gtkglext compiling against SDK 10.5?

Regards

Jacob Kolding

dacobi@...

EMAILING FOR THE GREATER GOOD
Join me

From: jacob@...
Date: Sun, 22 Nov 2009 11:49:44 +0100
To: braden@...
CC: gtk-devel-list@...; gtkglext-list@...; gtk-osx-users@...
Subject: Re: [Gtk-osx-users] [GtkGLExt] OS X Quartz developers Call to Arms

On Nov 21, 2009, at 6:30 AM, Braden McDaniel wrote:

On Sat, 2009-11-21 at 02:33 +0100, Jack Skellington wrote:
Hi all!

I'm currently working on porting a commercial Gtk+ OpenGL App to Snow
Leopard using the actively developed and maintained Gtk+ OS X Quartz
backend. My last problem now is that GtkGlExt only works with X11. I'm
not familiar with the Low Level OS X API's, so I'd properly wouldn't
be able to write the backend myself but I think it would be awesome if
someone here could help with the native OS X backend, getting closer
to a fully supported native Gtk+ :)

This patch is probably a good starting point:

https://sourceforge.net/tracker/?func=detail&aid=2750584&group_id=54333&atid=473436

I'll try to get back to reviewing this soon; though it might have to
wait until I get my KVM back from RMA.

Do let me know how it goes for you.

I managed to apply the patch and compile both GtkGLExt and my app, but when I start my app
the main windows is complete empty of any gtk widgets (white background everywhere), the only thing thats visible is the borders I draw in the opengl area, but
when I move the mouse up the the invisible file menu I'm able to open other (non opengl) windows which works as expected??

Regards
Jacob Kolding
dacobi@...

--
Braden McDaniel <braden@...>

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

smime.p7s (2K) Download Attachment

Re: [Gtk-osx-users] OS X Quartz developers Call to Arms

2009-11-23T08:35:18Z

Cool... did not even know there was a list for gtkglext.

I actually have some need of this. Just don't have time to work it, not sure if I have the know how either.. I am swamped with other work.

I myself do not have a good grasp of the Next Step Windowing system, but it looks like the implementation uses the NSView (check in gdkglwindow-quartz.h) instead of the NSOpenGLView, which means (given the dates on the patch) that some of this needs to be changed before it will work.

I bet you if you just change these lines to use the new NSOpenGLView it may indeed work

gdk/quartz/gdkglcontext-quartz.c:294: NSView *quartzView; gdk/quartz/gdkglcontext-quartz.c:325: name: NSViewFrameDidChangeNotification gdk/quartz/gdkglwindow-quartz.c:127: NSView *quartzView; gdk/quartz/gdkglwindow-quartz.c:184: NSView *view = GDK_GL_WINDOW_IMPL_QUARTZ (draw)->quartzView; gdk/quartz/gdkglwindow-quartz.h:23: NSView *quartzView;

EMAILING FOR THE GREATER GOOD
Join me

From: jacob@...
Date: Sun, 22 Nov 2009 11:49:44 +0100
To: braden@...
CC: gtk-devel-list@...; gtkglext-list@...; gtk-osx-users@...
Subject: Re: [Gtk-osx-users] [GtkGLExt] OS X Quartz developers Call to Arms

On Nov 21, 2009, at 6:30 AM, Braden McDaniel wrote:

On Sat, 2009-11-21 at 02:33 +0100, Jack Skellington wrote:
Hi all!

I'm currently working on porting a commercial Gtk+ OpenGL App to Snow
Leopard using the actively developed and maintained Gtk+ OS X Quartz
backend. My last problem now is that GtkGlExt only works with X11. I'm
not familiar with the Low Level OS X API's, so I'd properly wouldn't
be able to write the backend myself but I think it would be awesome if
someone here could help with the native OS X backend, getting closer
to a fully supported native Gtk+ :)

This patch is probably a good starting point:

https://sourceforge.net/tracker/?func=detail&aid=2750584&group_id=54333&atid=473436

I'll try to get back to reviewing this soon; though it might have to
wait until I get my KVM back from RMA.

Do let me know how it goes for you.

I managed to apply the patch and compile both GtkGLExt and my app, but when I start my app

the main windows is complete empty of any gtk widgets (white background everywhere), the only thing thats visible is the borders I draw in the opengl area, but

when I move the mouse up the the invisible file menu I'm able to open other (non opengl) windows which works as expected??

Regards

Jacob Kolding
dacobi@...

--
Braden McDaniel <braden@...>

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: OpenGL widget fills entire window on OS X [was: OS X Quartz developers...]

2009-11-22T23:21:12Z

Hello.
The problem with non-OpenGL widgets takes place only with new GTK versions.
Then I wrote this patch and test it with gtk 2.14 beta framework build and some later builds (built with jhbuild script) this problem does not appear.
Unfortunately I have not free time now but I hope to get it soon and spend some for this project.
There are no Low Level API used in my patch. Only NSOpenglView, NSOpenglContext and some related functions.

Andrey.

On 22.11.2009, at 20:27, Jack Skellington wrote:

> The problem seems to be that when rendering to the OpenGL capable
> widget it expands to fill the entire window.
> If I resize the window the gtk widgets are visible for a split second
> before they are covered with white background.
> But the OpenGL rendering works fine otherwise.
>
> This is my main rendering loop:
>
> gboolean G_MODULE_EXPORT render(gpointer data){
>
> GtkWidget *widget = GTK_WIDGET(data);
>
> GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
> GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);
>
> if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
> return FALSE;
>
>
> glClearColor (1.0, 1.0, 1.0, 1.0);
> glClearDepth (1.0);
> glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>
> engineIteration();
>
> gdk_gl_drawable_swap_buffers (gldrawable);
>
> gdk_gl_drawable_gl_end (gldrawable);
>
> return TRUE;
> }
>
> Regards
> Jacob K
>
> On Sun, Nov 22, 2009 at 11:49 AM, Jacob Juul Kolding <jacob@...> wrote:
>> On Nov 21, 2009, at 6:30 AM, Braden McDaniel wrote:
>>
>> On Sat, 2009-11-21 at 02:33 +0100, Jack Skellington wrote:
>>
>> Hi all!
>>
>> I'm currently working on porting a commercial Gtk+ OpenGL App to Snow
>>
>> Leopard using the actively developed and maintained Gtk+ OS X Quartz
>>
>> backend. My last problem now is that GtkGlExt only works with X11. I'm
>>
>> not familiar with the Low Level OS X API's, so I'd properly wouldn't
>>
>> be able to write the backend myself but I think it would be awesome if
>>
>> someone here could help with the native OS X backend, getting closer
>>
>> to a fully supported native Gtk+ :)
>>
>> This patch is probably a good starting point:
>>
>> https://sourceforge.net/tracker/?func=detail&aid=2750584&group_id=54333&atid=473436
>>
>> I'll try to get back to reviewing this soon; though it might have to
>> wait until I get my KVM back from RMA.
>>
>> Do let me know how it goes for you.
>>
>> I managed to apply the patch and compile both GtkGLExt and my app, but when
>> I start my app
>> the main windows is complete empty of any gtk widgets (white background
>> everywhere), the only thing thats visible is the borders I draw in the
>> opengl area, but
>> when I move the mouse up the the invisible file menu I'm able to open other
>> (non opengl) windows which works as expected??
>> Regards
>> Jacob Kolding
>> dacobi@...
>>
>> --
>> Braden McDaniel <braden@...>
>>
>> _______________________________________________
>> gtkglext-list mailing list
>> gtkglext-list@...
>> http://mail.gnome.org/mailman/listinfo/gtkglext-list
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Gtk-osx-users mailing list
>> Gtk-osx-users@...
>> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
>>
>>
> _______________________________________________
> gtkglext-list mailing list
> gtkglext-list@...
> http://mail.gnome.org/mailman/listinfo/gtkglext-list

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

OpenGL widget fills entire window on OS X [was: OS X Quartz developers...]

2009-11-22T09:27:01Z

The problem seems to be that when rendering to the OpenGL capable
widget it expands to fill the entire window.
If I resize the window the gtk widgets are visible for a split second
before they are covered with white background.
But the OpenGL rendering works fine otherwise.

This is my main rendering loop:

gboolean G_MODULE_EXPORT render(gpointer data){

GtkWidget *widget = GTK_WIDGET(data);

GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);

if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
return FALSE;

glClearColor (1.0, 1.0, 1.0, 1.0);
glClearDepth (1.0);
glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

engineIteration();

gdk_gl_drawable_swap_buffers (gldrawable);

gdk_gl_drawable_gl_end (gldrawable);

return TRUE;
}

Regards
Jacob K

On Sun, Nov 22, 2009 at 11:49 AM, Jacob Juul Kolding <jacob@...> wrote:

> On Nov 21, 2009, at 6:30 AM, Braden McDaniel wrote:
>
> On Sat, 2009-11-21 at 02:33 +0100, Jack Skellington wrote:
>
> Hi all!
>
> I'm currently working on porting a commercial Gtk+ OpenGL App to Snow
>
> Leopard using the actively developed and maintained Gtk+ OS X Quartz
>
> backend. My last problem now is that GtkGlExt only works with X11. I'm
>
> not familiar with the Low Level OS X API's, so I'd properly wouldn't
>
> be able to write the backend myself but I think it would be awesome if
>
> someone here could help with the native OS X backend, getting closer
>
> to a fully supported native Gtk+ :)
>
> This patch is probably a good starting point:
>
> https://sourceforge.net/tracker/?func=detail&aid=2750584&group_id=54333&atid=473436
>
> I'll try to get back to reviewing this soon; though it might have to
> wait until I get my KVM back from RMA.
>
> Do let me know how it goes for you.
>
> I managed to apply the patch and compile both GtkGLExt and my app, but when
> I start my app
> the main windows is complete empty of any gtk widgets (white background
> everywhere), the only thing thats visible is the borders I draw in the
> opengl area, but
> when I move the mouse up the the invisible file menu I'm able to open other
> (non opengl) windows which works as expected??
> Regards
> Jacob Kolding
> dacobi@...
>
> --
> Braden McDaniel <braden@...>
>
> _______________________________________________
> gtkglext-list mailing list
> gtkglext-list@...
> http://mail.gnome.org/mailman/listinfo/gtkglext-list
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Gtk-osx-users mailing list
> Gtk-osx-users@...
> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
>
>

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: OS X Quartz developers Call to Arms

2009-11-22T02:49:44Z

On Nov 21, 2009, at 6:30 AM, Braden McDaniel wrote:

On Sat, 2009-11-21 at 02:33 +0100, Jack Skellington wrote:
Hi all!

I'm currently working on porting a commercial Gtk+ OpenGL App to Snow
Leopard using the actively developed and maintained Gtk+ OS X Quartz
backend. My last problem now is that GtkGlExt only works with X11. I'm
not familiar with the Low Level OS X API's, so I'd properly wouldn't
be able to write the backend myself but I think it would be awesome if
someone here could help with the native OS X backend, getting closer
to a fully supported native Gtk+ :)

This patch is probably a good starting point:

https://sourceforge.net/tracker/?func=detail&aid=2750584&group_id=54333&atid=473436

I'll try to get back to reviewing this soon; though it might have to
wait until I get my KVM back from RMA.

Do let me know how it goes for you.

I managed to apply the patch and compile both GtkGLExt and my app, but when I start my app

the main windows is complete empty of any gtk widgets (white background everywhere), the only thing thats visible is the borders I draw in the opengl area, but

when I move the mouse up the the invisible file menu I'm able to open other (non opengl) windows which works as expected??

Regards

Jacob Kolding
dacobi@...

--
Braden McDaniel <braden@...>

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

smime.p7s (2K) Download Attachment

Re: OS X Quartz developers Call to Arms

2009-11-20T21:30:05Z

On Sat, 2009-11-21 at 02:33 +0100, Jack Skellington wrote:
> Hi all!
>
> I'm currently working on porting a commercial Gtk+ OpenGL App to Snow
> Leopard using the actively developed and maintained Gtk+ OS X Quartz
> backend. My last problem now is that GtkGlExt only works with X11. I'm
> not familiar with the Low Level OS X API's, so I'd properly wouldn't
> be able to write the backend myself but I think it would be awesome if
> someone here could help with the native OS X backend, getting closer
> to a fully supported native Gtk+ :)

This patch is probably a good starting point:

https://sourceforge.net/tracker/?func=detail&aid=2750584&group_id=54333&atid=473436

I'll try to get back to reviewing this soon; though it might have to
wait until I get my KVM back from RMA.

Do let me know how it goes for you.

--
Braden McDaniel <braden@...>

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

OS X Quartz developers Call to Arms

2009-11-20T17:33:36Z

Hi all!

I'm currently working on porting a commercial Gtk+ OpenGL App to Snow
Leopard using the actively developed and maintained Gtk+ OS X Quartz
backend. My last problem now is that GtkGlExt only works with X11. I'm
not familiar with the Low Level OS X API's, so I'd properly wouldn't
be able to write the backend myself but I think it would be awesome if
someone here could help with the native OS X backend, getting closer
to a fully supported native Gtk+ :)

Regards
Jacob Juul Kolding
Juvul Tech
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Repositories on git.gnome.org

2009-10-19T11:27:27Z

On Wed, Oct 14, 2009 at 03:30:37PM +0530, Mukund Sivaraman wrote:
> 1. It is possible for a committer to create new git.gnome.org
> repositories automatically without any 3rd party (human) involvement.
> [Btw, we should create separate repositories for gtkglext, gtkglextmm,
> etc. due to the way the code and history are organized.]

The following git repositories are now available:

http://git.gnome.org/cgit/gtkglext/
http://git.gnome.org/cgit/gtkglext-sharp/
http://git.gnome.org/cgit/gtkglextmm/
http://git.gnome.org/cgit/pygtkglext/

Please let's use these from now on. I'll push my patches soon. I have
to rebase them against the new gtkglext tree as they are currently
against where Naofumi left off.

Ralf: If you do not have a GNOME committer account, we'll get one for
you. Have you applied for one, and do you have a request tracker
number for it?

Mukund
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: My GtkGLExt updates and request to take maintainership

2009-10-14T03:00:37Z

On Wed, Oct 14, 2009 at 05:42:03AM +0200, Ralf Corsepius wrote:

> On 10/14/2009 12:17 AM, Braden McDaniel wrote:
>
>> We've actually been trying to migrate the project to gnome.org for more
>> than a year. This has been a bit of a fiasco. Some of the delays in
>> responsiveness were on our end; but most of them weren't. Things petered
>> out some months ago after repeated attempts to get Ralf Corsepius a
>> gnome.org account were met with no response. Assuming Ralf wishes to
>> remain attached to this project
>
> I do. However, the way gnome.org processed our attempt to move the
> project to gnome.org has caused my interest in further pursuing a mover
> of gtkglext to gnome.org to a minimum.

Let's see what needs to be done to move it to gnome.org:

1. It is possible for a committer to create new git.gnome.org
repositories automatically without any 3rd party (human) involvement.
[Btw, we should create separate repositories for gtkglext, gtkglextmm,
etc. due to the way the code and history are organized.]

2. There is a bugzilla.gnome.org component for GtkGLExt already.

3. There is this mailing list.

What remains are accounts to commit to the repository. I have one. Do
you and Braden have accounts too?

Ralf: If you're still waiting for an account, we'll create this
repository and I'll see to it that you get your account after that.
You can not only commit to GtkGLExt, but any of the hundred odd GNOME
projects after that (assuming your patches are reviewed and accepted by
maintainers of that project, of course :).

Until you get the account, you can have GtkGLExt patches from you
committed by any gnome.org committer (git separates the concept of
author and committer, so the patches are committed in your name to the
repo).

GtkGLExt is a GTK+ related project which is considered for inclusion
into GTK+ someday (Project Ridley or not). It belongs at gnome.org.
You have several more GNOME developers looking at it, and readily able
to commit to it.

Mukund
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: My GtkGLExt updates and request to take maintainership

2009-10-13T20:42:03Z

On 10/14/2009 12:17 AM, Braden McDaniel wrote:

> We've actually been trying to migrate the project to gnome.org for more
> than a year. This has been a bit of a fiasco. Some of the delays in
> responsiveness were on our end; but most of them weren't. Things petered
> out some months ago after repeated attempts to get Ralf Corsepius a
> gnome.org account were met with no response. Assuming Ralf wishes to
> remain attached to this project

I do. However, the way gnome.org processed our attempt to move the
project to gnome.org has caused my interest in further pursuing a mover
of gtkglext to gnome.org to a minimum.

> and assuming the idea of moving to
> gnome.org isn't met with complete derision by the current comaintainers,
> that is the first problem that would need solving.
I regret having to say so, but provided the way gnome.org processed our
attempt to move the project to gnome.org, I am not sure further pursuing
a mover of gtkglext to gnome.org is a good idea.

> For my part, I see migration to gnome.org as something of an
> inevitability because I see this project's future (if it has one at all)
> as including absorption into GTK+ proper in some form. I think moving to
> gnome.org raises this project's visibility among GNOME developers and
> hopefully facilitates realization of that future.
Well, only if gnome.org changes their attitude. Otherwise gtkglext is
likely better off staying with sourceforge or with moving to another site.

> So I'm the easy sell. But you may need to convince folks here that a
> move to gnome.org won't make administrative tasks completely impossible.
> Because, frankly, that's how it looks to us right now.
Correct.

Ralf

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: My GtkGLExt updates and request to take maintainership

2009-10-13T15:17:41Z

On 10/13/09 4:23 PM, Mukund Sivaraman wrote:

> Hi all
>
> I have put up a git repository of my modifications to GtkGLExt at
> <https://www.banu.com/git/?p=gtkglext.git;a=summary>.
>
> The commit log should be self-explanatory. The major change is an
> upgrade of OpenGL's extensions to current headers as published by the
> Khronos Group. There are some bug fixes too. This work is based on
> where Naofumi left off (since then, except for bugfixes to examples,
> and automake files, nothing major has changed).
>
> The TODO list has a bunch of items for what needs to be done. I want to
> do a few more changes at least:
>
> 1. The wrappers around OpenGL extensions API need to be made more GLee
> like, and use less memory. Currently it's a pain to use the GtkGLExt
> wrappers.
>
> 2. Update the Pango backend which we use. The current code uses Pango X
> which is obsolete.
>
> 3. Move the repository to git.gnome.org, use bugzilla.gnome.org to
> track bugs (currently it lists just 1) and move the website to
> <http://projects.gnome.org/gtkglext/>. gnome.org is a preferred home
> for it where several more GNOME developers will get commit access to
> its repositories by default. I am a member of the GNOME foundation and
> can get this sorted if current maintainers are fine with it.
>
> 4. Make some automake related changes.
>
> I also request to take up maintainership of GtkGLExt. It doesn't seem
> actively maintained currently.

Well, I'd say it's semi-actively maintained.

It is hard to deny that the current maintainers (of which I'm one) are
lacking the time and/or interest to give this project the attention that
it needs.

I'm going to review your changes; but their intent, at least, sounds
good. I'd welcome the addition of a person willing and able to
modernize GtkGLExt appropriately. Speaking for myself, I'd like to
remain attached to the project as a comaintainer.

We've actually been trying to migrate the project to gnome.org for more
than a year. This has been a bit of a fiasco. Some of the delays in
responsiveness were on our end; but most of them weren't. Things
petered out some months ago after repeated attempts to get Ralf
Corsepius a gnome.org account were met with no response. Assuming Ralf
wishes to remain attached to this project and assuming the idea of
moving to gnome.org isn't met with complete derision by the current
comaintainers, that is the first problem that would need solving.

For my part, I see migration to gnome.org as something of an
inevitability because I see this project's future (if it has one at all)
as including absorption into GTK+ proper in some form. I think moving
to gnome.org raises this project's visibility among GNOME developers and
hopefully facilitates realization of that future.

So I'm the easy sell. But you may need to convince folks here that a
move to gnome.org won't make administrative tasks completely impossible.
Because, frankly, that's how it looks to us right now.

--
Braden McDaniel e-mail: <braden@...>
<http://endoframe.com> Jabber: <braden@...>
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: My GtkGLExt updates and request to take maintainership

2009-10-13T13:28:51Z

On Wed, Oct 14, 2009 at 01:53:21AM +0530, Mukund Sivaraman wrote:
> I have put up a git repository of my modifications to GtkGLExt at
> <https://www.banu.com/git/?p=gtkglext.git;a=summary>.

You can see an example of GLSL with GtkGLExt here:
https://www.banu.com/blog/2009/10/13/glsl-with-gtkglext/

The video on that page was captured by using Istanbul on Fedora 11,
with an NVIDIA chipset and the proprietary NVIDIA driver.

Mukund
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

My GtkGLExt updates and request to take maintainership

2009-10-13T13:23:21Z

Hi all

I have put up a git repository of my modifications to GtkGLExt at
<https://www.banu.com/git/?p=gtkglext.git;a=summary>.

The commit log should be self-explanatory. The major change is an
upgrade of OpenGL's extensions to current headers as published by the
Khronos Group. There are some bug fixes too. This work is based on
where Naofumi left off (since then, except for bugfixes to examples,
and automake files, nothing major has changed).

The TODO list has a bunch of items for what needs to be done. I want to
do a few more changes at least:

1. The wrappers around OpenGL extensions API need to be made more GLee
like, and use less memory. Currently it's a pain to use the GtkGLExt
wrappers.

2. Update the Pango backend which we use. The current code uses Pango X
which is obsolete.

3. Move the repository to git.gnome.org, use bugzilla.gnome.org to
track bugs (currently it lists just 1) and move the website to
<http://projects.gnome.org/gtkglext/>. gnome.org is a preferred home
for it where several more GNOME developers will get commit access to
its repositories by default. I am a member of the GNOME foundation and
can get this sorted if current maintainers are fine with it.

4. Make some automake related changes.

I also request to take up maintainership of GtkGLExt. It doesn't seem
actively maintained currently.

Mukund
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

gtkglextmm and glewinit simple question

2009-09-15T07:50:22Z

i have this very simple problem, yet i havent found any solution.

i got this code:
[code]
int main(int argc, char **argv){
GLenum initStatus = glewInit();
if( initStatus != GLEW_OK ){
printf( "*GLEW Cannot Init\n");
}
if( GLEW_ARB_vertex_buffer_object == NULL ){
printf( "*GLEW_ARB_vertex_buffer_object = NULL\n");
}
Gtk::Main m(argc, argv);

// Init gtkglextmm.
Gtk::GL::init(argc, argv);

// Query OpenGL extension version.
int major, minor;
Gdk::GL::query_version(major, minor);
std::cout << "OpenGL extension version - "<< major << "." << minor << std::endl;
GUIVentanaPrincipal gui;
m.run(gui);

return 0;
}
[/code]

but glewinit fails to initialize
this is my output
[code]
*GLEW Cannot Init
*GLEW_ARB_vertex_buffer_object = NULL
OpenGL extension version - 1.4
[/code]

why this happens when using gtkglextmm and glew?, it only happens on this project im working.

building pygtkglext

2009-09-14T17:15:00Z

Hello,
I am trying to build gtkglext and pygtkglext on a RHEL 5.3 workstation. I downloaded both tarballs, and successfully built the gtkglext library and some of the demos. I do not have root access to this workstation, so I installed everything to $HOME/lib. I then untarred the python wrappers, and attempted to buld them using both setup.py and configure. Setup.py fails when it cannot find the gtkglext install. configure/make also fails, though I don't remember the specific error that occurs - I think it had to do with not finding the gtkglext defs files.. Is there any way to build the python wrappers when the gtkglext libraries are installed in a non-standard location?

Thanks,
Ray

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: Updated example source code using GtkBuilder and GtkGLExt. (Mitchell Laks)

2009-09-08T05:40:01Z

Hi Mitchell,
Hey, thanks for the email! I was using an email client
and did not realise it mangled my formatting as such! Have reposted the
previous entries to the list. Thanks!

Regards,
Jose.

> Dear axora,
> I would love to read you messages but I cant because they were all sent in html mail. I would be very grateful if you could
> resend them without the html noise :(.
> Thank you very much!
> Mitchell
>
>
>
>
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

[Repost] Re: GdkGLPixmap troubles

2009-09-08T05:38:32Z

Lindley, I think I've just spotted what the problem may be. In your
code you have this:

gboolean reshapeGL(GtkWidget *widget, GdkEventConfigure *evnt, gpointer
data)
{
GUIWindow* me = (GUIWindow*)data;

There's a quirk in using the 'gpointer data' object in a GTK
function - it actually gets swapped in the stack if you do so, and is
*not recommended* :P.
The best approach is to not use the 'gpointer data' at all; instead,
if you want to pass your user data to a GTK function, attach a GObject
to it like so - in this example I am attaching it to the window
containing the GL context:

(-in place of setting the user data in your initialisation code-)
g_object_set_data ((GObject *)theWindowWithYourGLContext,
"myUserData", &theActualData);

And then use something like this to retrieve it:

gboolean reshapeGL(GtkWidget *widget, GdkEventConfigure *evnt, gpointer
data)
{
GUIWindow* me = g_object_get_data ((GObject
*)gtk_widget_get_toplevel (widget), "myUserData")));

In your reshape (and other) functions that need it.

Regards,
Jose.
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

[Repost] Updated example source code using GtkBuilder and GtkGLExt

2009-09-08T05:35:08Z

(Update)

Hi folks, to help out anyone who is looking into using OpenGL within GTK
windows (using GtkGLExt) I have released fully documented sample code in
C to be used freely as you wish.

It provides safe render-process locking and smooth timer-based rendering
while being simple, efficient and easy to understand what is going on.

The demo has been updated to use GtkBuilder and is now hosted on
Sourceforge: http://gtkglapp.sourceforge.net/

To import the project into Eclipse IDE:
Open the menu 'File->Import...'.
From the 'General' options folder, select 'Existing Projects into
Workspace' and click on the 'Next >' button.
Choose the 'Select archive file:' option and next to it click on the
'Browse...' button to navigate to the project archive (ending in '.tgz')
you downloaded.
The project name will appear below - click on 'Finish'.
The project will be imported and opened in your Eclipse workspace.

For command-line users:
Please note that to run the application successfully outside of the
Eclipse IDE environment (e.g. from a 'make' within the "../Debug/"
directory) the GUI file "gtk_gl_tester.gtk" must reside in the same
directory as the compiled binary for it to run.

Regards,
Jose.
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

[Repost] Re: GdkGLPixmap troubles

2009-09-08T05:33:00Z

Hi, just to note a few caveats when dealing with GL contexts.

First, before performing any context reference operations, the GL
widget should be +realized+ to manipulate any references inside. I have
included some source code that I use in one of my apps to enlighten.
with typecasts to make it easier to associate types:

// Get OpenGL rendering context.
gtk_widget_realize ((GtkWidget *) yourGLCapableWidget);
(GdkGLContext *) theSharedGlContext = gtk_widget_get_gl_context
((GtkWidget *) yourGLCapableWidget);
// Initialise the other GL areas with the same shared context.
(GtkWidget *) anotherGLWidget = GTK_WIDGET (gtk_builder_get_object
(yourGTKBuilderXml, "GLwidget2"));
// Add OpenGL-capability to the other widget, sharing the same context.
gtk_widget_set_gl_capability ((GtkWidget *) anotherGLWidget,
glConfig, (GdkGLContext *) theSharedGlContext, TRUE, GDK_GL_RGBA_TYPE);

... etc

Note that 'gtk_widget_realize' is essential for the following
functions to reference data within.

Another caveat is that some drivers align texture data, depending on
hardware - after the storage->framebuffer phase the alignment can vary
if the hardware is not capable of non-powers-of-two textures. You may
find that the driver will texture-split any non-power-of-two
rectangles. The solution to this is to make sure that if the
driver/hardware does not support non-power-of-two textures, to use the
stride value in retrieving data back from the framebuffer.

Regards,
Jose.
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: Updated example source code using GtkBuilder and GtkGLExt..

2009-09-06T06:21:57Z

On 14:37 Thu 27 Aug , axora@... wrote:

> <html><body>(Update) Hi folks, to help out anyone who is looking into
> using OpenGL within GTK windows (using GtkGLExt) I have released fully
> documented sample code in C to be used freely as you wish.
> 
>
> It provides safe render-process locking and smooth timer-based
> rendering while being simple, efficient and easy to understand what is
> going on.
> 
>
> 
> The demo has been updated to use GtkBuilder and is now hosted on Sourceforge: <a href="http://gtkglapp.sourceforge.net/" target="_blank" class="postlink">http://gtkglapp.sourceforge.net/</a>
> 
>
> 
> To import the project into Eclipse IDE:
> 
> Open the menu 'File->Import...'.
> 
> From the 'General' options folder, select 'Existing Projects into Workspace' and click on the 'Next >' button.
> 
> Choose the 'Select archive file:' option and next to it click on the 'Browse...' button to navigate to the project archive (ending in '.tgz') you downloaded.
> 
> The project name will appear below - click on 'Finish'.
> 
> The project will be imported and opened in your Eclipse workspace.
> 
>
> 
> For command-line users:
> Please note that to run the application successfully outside of the
> Eclipse IDE environment (e.g. from a 'make' within the "../Debug/"
> directory) the GUI file "gtk_gl_tester.gtk" must reside in the same
> directory as the compiled binary for it to run. Regards, Jose. </body></html>

Dear axora,
I would love to read you messages but I cant because they were all sent in html mail. I would be very grateful if you could
resend them without the html noise :(.
Thank you very much!
Mitchell

> _______________________________________________
> gtkglext-list mailing list
> gtkglext-list@...
> http://mail.gnome.org/mailman/listinfo/gtkglext-list

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: GdkGLPixmap troubles

2009-08-28T11:46:36Z

    Lindley, I think I've just spotted what the problem may be. In your code you have this:

gboolean reshapeGL(GtkWidget *widget, GdkEventConfigure *evnt, gpointer data)
{
GUIWindow* me = (GUIWindow*)data;

    There's a quirk in using the 'gpointer data' object in a GTK function - it actually gets swapped in the stack if you do so, and is *not recommended* :P.
    The best approach is to not use the 'gpointer data' at all; instead, if you want to pass your user data to a GTK function, attach a GObject to it like so - in this example I am attaching it to the window containing the GL context:

    (-in place of setting the user data in your initialisation code-)
    g_object_set_data ((GObject *)theWindowWithYourGLContext, "myUserData", &theActualData);

    And then use something like this to retrieve it:

gboolean reshapeGL(GtkWidget *widget, GdkEventConfigure *evnt, gpointer data)
{
    GUIWindow* me = g_object_get_data ((GObject *)gtk_widget_get_toplevel (widget), "myUserData")));

    In your reshape (and other) functions that need it.

Regards,
        Jose.

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Updated example source code using GtkBuilder and GtkGLExt..

2009-08-27T14:37:11Z

(Update)

Hi folks, to help out anyone who is looking into using OpenGL within GTK windows (using GtkGLExt) I have released fully documented sample code in C to be used freely as you wish.

It provides safe render-process locking and smooth timer-based rendering while being simple, efficient and easy to understand what is going on.

The demo has been updated to use GtkBuilder and is now hosted on Sourceforge: http://gtkglapp.sourceforge.net/

To import the project into Eclipse IDE:
Open the menu 'File->Import...'.
From the 'General' options folder, select 'Existing Projects into Workspace' and click on the 'Next >' button.
Choose the 'Select archive file:' option and next to it click on the 'Browse...' button to navigate to the project archive (ending in '.tgz') you downloaded.
The project name will appear below - click on 'Finish'.
The project will be imported and opened in your Eclipse workspace.

For command-line users:
Please note that to run the application successfully outside of the Eclipse IDE environment (e.g. from a 'make' within the "../Debug/" directory) the GUI file "gtk_gl_tester.gtk" must reside in the same directory as the compiled binary for it to run.

Regards,
Jose.

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: GdkGLPixmap troubles

2009-08-27T14:33:07Z

    Hi, just to note a few caveats when dealing with GL contexts.

    First, before performing any context reference operations, the GL widget should be +realized+ to manipulate any references inside. I have included some source code that I use in one of my apps to enlighten. with typecasts to make it easier to associate types:

    // Get OpenGL rendering context.
    gtk_widget_realize ((GtkWidget *) yourGLCapableWidget);
    (GdkGLContext *) theSharedGlContext = gtk_widget_get_gl_context ((GtkWidget *) yourGLCapableWidget);
    // Initialise the other GL areas with the same shared context.
    (GtkWidget *) anotherGLWidget = GTK_WIDGET (gtk_builder_get_object (yourGTKBuilderXml, "GLwidget2"));
    // Add OpenGL-capability to the other widget, sharing the same context.
    gtk_widget_set_gl_capability ((GtkWidget *) anotherGLWidget, glConfig, (GdkGLContext *) theSharedGlContext, TRUE, GDK_GL_RGBA_TYPE);

... etc

    Note that 'gtk_widget_realize' is essential for the following functions to reference data within.

    Another caveat is that some drivers align texture data, depending on hardware - after the storage->framebuffer phase the alignment can vary if the hardware is not capable of non-powers-of-two textures. You may find that the driver will texture-split any non-power-of-two rectangles. The solution to this is to make sure that if the driver/hardware does not support non-power-of-two textures, to use the stride value in retrieving data back from the framebuffer.

Regards,
    Jose.

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: GdkGLPixmap troubles

2009-08-27T08:17:44Z

Ack, that looks messy. Anyway, here's my current code----all the objects and checks are sucessful, right up to the creation of the GdkPixbuf, but the damn thing is blank---no image in it. I even glClear()'d the buffer to green so I'd know it was getting *something*, but.....nope.

configure-event handler:

gboolean reshapeGL(GtkWidget *widget, GdkEventConfigure *evnt, gpointer data)
{
GUIWindow* me = (GUIWindow*)data;
GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);

assert(pthread_equal(me->mainthread, pthread_self()));

if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
return FALSE;

me->lock();
me->viewport.x = evnt->x;
me->viewport.width = evnt->width;
me->viewport.y = evnt->y;
me->viewport.height = evnt->height;
me->unlock();

gdk_gl_drawable_gl_end (gldrawable);

if (me->osPixmap)
gdk_gl_pixmap_destroy(me->osPixmap);
if (me->osContext)
gdk_gl_context_destroy(me->osContext);
GdkPixmap *pixmap = gdk_pixmap_new (widget->window,
widget->allocation.width,
widget->allocation.height,
-1);
GdkGLConfig *glconfig = gdk_gl_config_new_by_mode (
GdkGLConfigMode(GDK_GL_MODE_RGB |
GDK_GL_MODE_SINGLE));
me->osPixmap = gdk_pixmap_set_gl_capability (pixmap,
glconfig,
NULL);
me->osContext = gdk_gl_context_new (GDK_GL_DRAWABLE(me->osPixmap),
glcontext,
FALSE,
GDK_GL_RGBA_TYPE);
g_object_unref(glconfig);

return FALSE;
}

And here's my function to generate the Pixbuf:

gboolean doTakeScreenshot(gpointer data)
{
GUIWindow *me = (GUIWindow*)data;

assert(pthread_equal(me->mainthread, pthread_self()));

me->lock();

GdkGLDrawable *osDrawable = GDK_GL_DRAWABLE(me->osPixmap);
if (!osDrawable || !me->osContext)
{
fprintf(stderr, "Warning, no offscreen pixbuf configured in GUIWindow::doTakeScreenshot.\n");
me->signal(&me->screenshot_complete);
me->unlock();
return FALSE;
}

if (!me->screenshot_dest)
{
fprintf(stderr, "Warning, no screenshot destination found in GUIWindow::doTakeScreenshot.\n");
me->signal(&me->screenshot_complete);
me->unlock();
return FALSE;
}

if (!gdk_gl_drawable_gl_begin (osDrawable, me->osContext))
{
me->signal(&me->screenshot_complete);
me->unlock();
return FALSE;
}

glViewport(me->viewport.x,me->viewport.y,me->viewport.width,me->viewport.height);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity();

fprintf(stderr,"Taking screenshot of window %d.\n",me->window_id);

// Need to flip the y axis for screenshots
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(me->ortho.x,me->ortho.x+me->ortho.width,
me->ortho.y+me->ortho.height,me->ortho.y,0,1);
glMatrixMode(GL_MODELVIEW);

glClearColor(0,1,0,1);
glClear(GL_COLOR_BUFFER_BIT);
glColor3d(1,0,0);
glBegin(GL_LINES);
glVertex2d(me->ortho.x,me->ortho.y+me->ortho.height);
glVertex2d(me->ortho.x+me->ortho.width,me->ortho.y);
glEnd();

gdk_gl_drawable_wait_gl(osDrawable);

gdk_gl_drawable_gl_end (osDrawable);

me->osBuffer = gdk_pixbuf_get_from_drawable(me->osBuffer,
gdk_gl_pixmap_get_pixmap(me->osPixmap),
NULL,//gdk_color_get_system(),
0,0,0,0,-1,-1);

if (me->osBuffer)
{
color_img *img = me->screenshot_dest;
int pbheight = gdk_pixbuf_get_height (me->osBuffer);
int pbwidth = gdk_pixbuf_get_width (me->osBuffer);
int pbstride = gdk_pixbuf_get_rowstride (me->osBuffer);
int pbchannels = gdk_pixbuf_get_n_channels(me->osBuffer);
unsigned char *pixels = gdk_pixbuf_get_pixels(me->osBuffer);

assert(pbchannels == 3);

for (int i = 0; i < pbheight; i++)
{
for (int j = 0; j < pbwidth; j++)
{
memcpy(img->data[i][j],pixels + i*pbstride + j*pbchannels, pbchannels);
img->data[i][j][3] = 255;
}
}
}

me->signal(&me->screenshot_complete);

me->unlock();

return FALSE;
}

I breakpoint on the line after the gdk_pixbuf_get_pixels() call, and check the first few bytes----always 0. They should be (0,1,0) patterns since that's what I cleared the background too, or (1,0,0) if I happened to get a pixel with the red line on it.

Any idea what's wrong? If I don't hear back I'm scrapping the pixmap code as worthless and going to the tried-and-true render-to-texture via EXT_framebuffer_object approach. Even if that does require introducing a GLEW dependency.

----- Original Message -----
From: Stephane Popinet <s.popinet@...>
Date: Wednesday, August 26, 2009 5:20 pm
Subject: Re: [GtkGLExt] GdkGLPixmap troubles

> Hi Lindley, Jean,
>
> > Exporting a GL view is just a nightmare. Things seem to depend
> upon the
> > used driver. The solutioin I use can be seen at
> >
> http://svn.savannah.gnu.org/viewvc/trunk/gchemutils/libs/gcu/glview.cc?annotate=1098&root=gchemutils> starting from line 368. Not sure it works in all cases.
>
> Yes, I can confirm that doing offscreen openGL rendering in a portable
> way truly is a nightmare. It depends on the openGL driver and some
> drivers are so dodgy that they even tell you that they support
> offscreen openGL rendering when they don't.
>
> OSMesa is a good alternative, however it is not that well
> supported either...
>
> I would imagine offscreen openGL rendering to be something many people
> want to do but I am puzzled by the lack of ressources on the topic on
> the web. Are people using some other mechanism we are not aware of?
>
> Thanks for your code Jean, I will have a look and see if I can use it
> to improve mine (http://gfs.sf.net).
>
> cheers
>
> Stephane
> _______________________________________________
> gtkglext-list mailing list
> gtkglext-list@...
> http://mail.gnome.org/mailman/listinfo/gtkglext-list
>

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: GdkGLPixmap troubles

2009-08-26T14:54:25Z

Well, the "right" way to do it is to to EXT_framebuffer_object, which most graphics cards support these days. However, I'm trying to avoid introducing a GLEW or GLee dependency, and I hate dealing with OpenGL extensions manually. It's the principal of the thing.

----- Original Message -----
From: Stephane Popinet <s.popinet@...>
Date: Wednesday, August 26, 2009 5:20 pm
Subject: Re: [GtkGLExt] GdkGLPixmap troubles

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: GdkGLPixmap troubles

2009-08-26T14:20:30Z

Hi Lindley, Jean,

> Exporting a GL view is just a nightmare. Things seem to depend upon the
> used driver. The solutioin I use can be seen at
> http://svn.savannah.gnu.org/viewvc/trunk/gchemutils/libs/gcu/glview.cc?annotate=1098&root=gchemutils
> starting from line 368. Not sure it works in all cases.

Yes, I can confirm that doing offscreen openGL rendering in a portable
way truly is a nightmare. It depends on the openGL driver and some
drivers are so dodgy that they even tell you that they support
offscreen openGL rendering when they don't.

OSMesa is a good alternative, however it is not that well supported either...

I would imagine offscreen openGL rendering to be something many people
want to do but I am puzzled by the lack of ressources on the topic on
the web. Are people using some other mechanism we are not aware of?

Thanks for your code Jean, I will have a look and see if I can use it
to improve mine (http://gfs.sf.net).

cheers

Stephane
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: GdkGLPixmap troubles

2009-08-26T14:01:59Z

Exporting a GL view is just a nightmare. Things seem to depend upon the
used driver. The solutioin I use can be seen at
http://svn.savannah.gnu.org/viewvc/trunk/gchemutils/libs/gcu/glview.cc?annotate=1098&root=gchemutils
starting from line 368. Not sure it works in all cases.

Regards,
Jean

Le mercredi 26 août 2009 à 15:59 -0400, Lindley M French a écrit :

> Well, I've solve the initial issue---I was trying to cast a GdkPixmap when I should have been trying to cast a GdkGLPixmap. The bad cast warning was hidden because I'd forgotten I'd closed stderr on that program.
>
> However, the images aren't coming out right when the "host window" isn't on-screen. This is odd, since the pixmap is supposed to be sharing lists, textures, etc with the window's context, but not otherwise related to anything on-screen.
>
> It *looks* to me like what's getting drawn when the window is off-screen is a small part of the image, almost as if the orthographic projection were messed up; but I've checked that, it's fine. So is the viewport. So it must be something else?
>
> ----- Original Message -----
> From: Lindley M French <lfrench1@...>
> Date: Wednesday, August 26, 2009 2:46 pm
> Subject: [GtkGLExt] GdkGLPixmap troubles
>
> > I'm trying to allow an offscreen render to a pixmap to occur now,
> > instead of trying to force an expose event while a window is
> > offscreen like I was before.
> >
> > I've looked over the example code in pixmap.c that comes with
> > GtkGLExt, but my adaptation of it isn't working.
> >
> > My configure-event handler:
> >
> > gboolean reshapeGL(GtkWidget *widget, GdkEventConfigure *evnt,
> > gpointer data)
> > {
> > GUIWindow* me = (GUIWindow*)data;
> > GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
> > GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);
> >
> > assert(pthread_equal(me->mainthread, pthread_self()));
> > fprintf(stderr,"reshaping window %d, %d %d %d %d\n",me-
> > >window_id,evnt->x,evnt->y,evnt->width,evnt->height);
> >
> > if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
> > return FALSE;
> >
> > me->lock();
> > me->xviewport = evnt->x;
> > me->widthvp = evnt->width;
> > me->yviewport = evnt->y;
> > me->heightvp = evnt->height;
> > glViewport(me->xviewport,me->yviewport,me->widthvp,me->heightvp);
> > me->unlock();
> >
> > gdk_gl_drawable_gl_end (gldrawable);
> >
> > if (me->osPixmap)
> > g_object_unref(me->osPixmap);
> > if (me->osContext)
> > gdk_gl_context_destroy(me->osContext);
> > me->osPixmap = gdk_pixmap_new (widget->window,
> > widget->allocation.width,
> > widget->allocation.height,
> > -1);
> > GdkGLConfig *glconfig = gdk_gl_config_new_by_mode (
> > GdkGLConfigMode(GDK_GL_MODE_RGB |
> > GDK_GL_MODE_SINGLE));
> > GdkGLDrawable *osDrawable = GDK_GL_DRAWABLE (
> > gdk_pixmap_set_gl_capability (me->osPixmap,
> > glconfig,
> > NULL));
> > me->osContext = gdk_gl_context_new (osDrawable,
> > glcontext,
> > FALSE,
> > GDK_GL_RGBA_TYPE);
> >
> > return FALSE;
> > }
> >
> > That all works fine so far as I can tell. There may be some issues
> > with when exactly I'm supposed to unref something; the whole
> > reference counting scheme is less than well-documented. However,
> > I'm not concerned about that for now.
> >
> > I also have this function, which is not linked to any particular
> > event:
> > gboolean doTakeScreenshot(gpointer data)
> > {
> > GUIWindow *me = (GUIWindow *)data;
> >
> > assert(pthread_equal(me->mainthread, pthread_self()));
> >
> > me->lock();
> >
> > GdkGLDrawable *osDrawable = GDK_GL_DRAWABLE(me->osPixmap);
> > if (!osDrawable || !me->osContext)
> > {
> > fprintf(stderr, "Warning, no offscreen pixbuf configured
> > in aeGraphWindow::doTakeScreenshot.\n");
> > me->signal(&me->screenshot_complete);
> > me->unlock();
> > return FALSE;
> > }
> >
> > if (!gdk_gl_drawable_gl_begin (osDrawable, me->osContext))
> > {
> > me->signal(&me->screenshot_complete);
> > me->unlock();
> > return FALSE;
> > }
> >
> > // OPENGL DRAWING HERE
> >
> > gdk_gl_drawable_wait_gl(osDrawable);
> > glReadBuffer(GL_FRONT);
> > glReadPixels(me->xviewport,me->yviewport,me->widthvp,me->heightvp,
> > GL_RGBA,GL_UNSIGNED_BYTE,me->screenshot_dest-
> > >data[0]);
> > me->signal(&me->screenshot_complete);
> >
> > me->unlock();
> >
> > gdk_gl_drawable_gl_end (osDrawable);
> >
> > return FALSE;
> > }
> >
> > It appears that gdk_gl_drawable_gl_begin() is failing here. What
> > could cause that? Both the context and drawable being passed are
> > valid pointers. However, I did notice that
> > gdk_gl_context_get_gl_drawable(me->osContext) returned NULL, which
> > I thought was odd.
> >
> > I'm not positive that my glReadPixels() is valid either, but I
> > want to get past this hurdle before worrying about that one.
> >
> > Any ideas?
> > _______________________________________________
> > gtkglext-list mailing list
> > gtkglext-list@...
> > http://mail.gnome.org/mailman/listinfo/gtkglext-list
> >
> _______________________________________________
> gtk-list mailing list
> gtk-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Re: GdkGLPixmap troubles

2009-08-26T13:58:24Z

Okay, this is really odd.

I figured out why the on-screen case was working, that was just a remnant of my old code. But the GdkGLPixmap approach still isn't behaving itself. See the below code, with this inserted at the "OPENGL DRAWING HERE" point:

glClearColor(0,0,0,0);
glClear(GL_COLOR_BUFFER_BIT);
glColor3d(1,0,0);
glBegin(GL_LINES);
glVertex2d(me->ortho.x,me->ortho.y+me->ortho.height);
glVertex2d(me->ortho.x+me->ortho.width,me->ortho.y);
glEnd();

Obviously, this should draw a simple red line diagonally from one corner of the image to the other, since I'm using the same values for the vertexes as I did for the glOrtho() call.

However, the attached image is what comes out. One corner right, the other....not. *Something* fishy is going on....

----- Original Message -----
From: Lindley M French <lfrench1@...>
Date: Wednesday, August 26, 2009 3:59 pm
Subject: Re: [GtkGLExt] GdkGLPixmap troubles

> Well, I've solve the initial issue---I was trying to cast a
> GdkPixmap when I should have been trying to cast a GdkGLPixmap.
> The bad cast warning was hidden because I'd forgotten I'd closed
> stderr on that program.
>
> However, the images aren't coming out right when the "host window"
> isn't on-screen. This is odd, since the pixmap is supposed to be
> sharing lists, textures, etc with the window's context, but not
> otherwise related to anything on-screen.
>
> It *looks* to me like what's getting drawn when the window is off-
> screen is a small part of the image, almost as if the orthographic
> projection were messed up; but I've checked that, it's fine. So is
> the viewport. So it must be something else?
>
> ----- Original Message -----
> From: Lindley M French <lfrench1@...>
> Date: Wednesday, August 26, 2009 2:46 pm
> Subject: [GtkGLExt] GdkGLPixmap troubles
>
> > I'm trying to allow an offscreen render to a pixmap to occur
> now,
> > instead of trying to force an expose event while a window is
> > offscreen like I was before.
> >
> > I've looked over the example code in pixmap.c that comes with
> > GtkGLExt, but my adaptation of it isn't working.
> >
> > My configure-event handler:
> >
> > gboolean reshapeGL(GtkWidget *widget, GdkEventConfigure *evnt,
> > gpointer data)
> > {
> > GUIWindow* me = (GUIWindow*)data;
> > GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
> > GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);
> >
> > assert(pthread_equal(me->mainthread, pthread_self()));
> > fprintf(stderr,"reshaping window %d, %d %d %d %d\n",me-
> > >window_id,evnt->x,evnt->y,evnt->width,evnt->height);
> >
> > if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
> > return FALSE;
> >
> > me->lock();
> > me->xviewport = evnt->x;
> > me->widthvp = evnt->width;
> > me->yviewport = evnt->y;
> > me->heightvp = evnt->height;
> > glViewport(me->xviewport,me->yviewport,me->widthvp,me->heightvp);
> > me->unlock();
> >
> > gdk_gl_drawable_gl_end (gldrawable);
> >
> > if (me->osPixmap)
> > g_object_unref(me->osPixmap);
> > if (me->osContext)
> > gdk_gl_context_destroy(me->osContext);
> > me->osPixmap = gdk_pixmap_new (widget->window,
> > widget->allocation.width,
> > widget->allocation.height,
> > -1);
> > GdkGLConfig *glconfig = gdk_gl_config_new_by_mode (
> > GdkGLConfigMode(GDK_GL_MODE_RGB |
> > GDK_GL_MODE_SINGLE));
> > GdkGLDrawable *osDrawable = GDK_GL_DRAWABLE (
> > gdk_pixmap_set_gl_capability (me->osPixmap,
> > glconfig,
> > NULL));
> > me->osContext = gdk_gl_context_new (osDrawable,
> > glcontext,
> > FALSE,
> > GDK_GL_RGBA_TYPE);
> >
> > return FALSE;
> > }
> >
> > That all works fine so far as I can tell. There may be some
> issues
> > with when exactly I'm supposed to unref something; the whole
> > reference counting scheme is less than well-documented. However,
> > I'm not concerned about that for now.
> >
> > I also have this function, which is not linked to any particular
> > event:
> > gboolean doTakeScreenshot(gpointer data)
> > {
> > GUIWindow *me = (GUIWindow *)data;
> >
> > assert(pthread_equal(me->mainthread, pthread_self()));
> >
> > me->lock();
> >
> > GdkGLDrawable *osDrawable = GDK_GL_DRAWABLE(me->osPixmap);
> > if (!osDrawable || !me->osContext)
> > {
> > fprintf(stderr, "Warning, no offscreen pixbuf configured
> > in aeGraphWindow::doTakeScreenshot.\n");
> > me->signal(&me->screenshot_complete);
> > me->unlock();
> > return FALSE;
> > }
> >
> > if (!gdk_gl_drawable_gl_begin (osDrawable, me->osContext))
> > {
> > me->signal(&me->screenshot_complete);
> > me->unlock();
> > return FALSE;
> > }
> >
> > // OPENGL DRAWING HERE
> >
> > gdk_gl_drawable_wait_gl(osDrawable);
> > glReadBuffer(GL_FRONT);
> > glReadPixels(me->xviewport,me->yviewport,me->widthvp,me-
> >heightvp,> GL_RGBA,GL_UNSIGNED_BYTE,me-
> >screenshot_dest-
> > >data[0]);
> > me->signal(&me->screenshot_complete);
> >
> > me->unlock();
> >
> > gdk_gl_drawable_gl_end (osDrawable);
> >
> > return FALSE;
> > }
> >
> > It appears that gdk_gl_drawable_gl_begin() is failing here. What
> > could cause that? Both the context and drawable being passed are
> > valid pointers. However, I did notice that
> > gdk_gl_context_get_gl_drawable(me->osContext) returned NULL,
> which
> > I thought was odd.
> >
> > I'm not positive that my glReadPixels() is valid either, but I
> > want to get past this hurdle before worrying about that one.
> >
> > Any ideas?
> > _______________________________________________
> > gtkglext-list mailing list
> > gtkglext-list@...
> > http://mail.gnome.org/mailman/listinfo/gtkglext-list
> >
> _______________________________________________
> gtkglext-list mailing list
> gtkglext-list@...
> http://mail.gnome.org/mailman/listinfo/gtkglext-list
>

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

test1.png (5K) Download Attachment

Re: GdkGLPixmap troubles

2009-08-26T12:59:40Z

Well, I've solve the initial issue---I was trying to cast a GdkPixmap when I should have been trying to cast a GdkGLPixmap. The bad cast warning was hidden because I'd forgotten I'd closed stderr on that program.

However, the images aren't coming out right when the "host window" isn't on-screen. This is odd, since the pixmap is supposed to be sharing lists, textures, etc with the window's context, but not otherwise related to anything on-screen.

It *looks* to me like what's getting drawn when the window is off-screen is a small part of the image, almost as if the orthographic projection were messed up; but I've checked that, it's fine. So is the viewport. So it must be something else?

----- Original Message -----
From: Lindley M French <lfrench1@...>
Date: Wednesday, August 26, 2009 2:46 pm
Subject: [GtkGLExt] GdkGLPixmap troubles

> I'm trying to allow an offscreen render to a pixmap to occur now,
> instead of trying to force an expose event while a window is
> offscreen like I was before.
>
> I've looked over the example code in pixmap.c that comes with
> GtkGLExt, but my adaptation of it isn't working.
>
> My configure-event handler:
>
> gboolean reshapeGL(GtkWidget *widget, GdkEventConfigure *evnt,
> gpointer data)
> {
> GUIWindow* me = (GUIWindow*)data;
> GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
> GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);
>
> assert(pthread_equal(me->mainthread, pthread_self()));
> fprintf(stderr,"reshaping window %d, %d %d %d %d\n",me-
> >window_id,evnt->x,evnt->y,evnt->width,evnt->height);
>
> if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
> return FALSE;
>
> me->lock();
> me->xviewport = evnt->x;
> me->widthvp = evnt->width;
> me->yviewport = evnt->y;
> me->heightvp = evnt->height;
> glViewport(me->xviewport,me->yviewport,me->widthvp,me->heightvp);
> me->unlock();
>
> gdk_gl_drawable_gl_end (gldrawable);
>
> if (me->osPixmap)
> g_object_unref(me->osPixmap);
> if (me->osContext)
> gdk_gl_context_destroy(me->osContext);
> me->osPixmap = gdk_pixmap_new (widget->window,
> widget->allocation.width,
> widget->allocation.height,
> -1);
> GdkGLConfig *glconfig = gdk_gl_config_new_by_mode (
> GdkGLConfigMode(GDK_GL_MODE_RGB |
> GDK_GL_MODE_SINGLE));
> GdkGLDrawable *osDrawable = GDK_GL_DRAWABLE (
> gdk_pixmap_set_gl_capability (me->osPixmap,
> glconfig,
> NULL));
> me->osContext = gdk_gl_context_new (osDrawable,
> glcontext,
> FALSE,
> GDK_GL_RGBA_TYPE);
>
> return FALSE;
> }
>
> That all works fine so far as I can tell. There may be some issues
> with when exactly I'm supposed to unref something; the whole
> reference counting scheme is less than well-documented. However,
> I'm not concerned about that for now.
>
> I also have this function, which is not linked to any particular
> event:
> gboolean doTakeScreenshot(gpointer data)
> {
> GUIWindow *me = (GUIWindow *)data;
>
> assert(pthread_equal(me->mainthread, pthread_self()));
>
> me->lock();
>
> GdkGLDrawable *osDrawable = GDK_GL_DRAWABLE(me->osPixmap);
> if (!osDrawable || !me->osContext)
> {
> fprintf(stderr, "Warning, no offscreen pixbuf configured
> in aeGraphWindow::doTakeScreenshot.\n");
> me->signal(&me->screenshot_complete);
> me->unlock();
> return FALSE;
> }
>
> if (!gdk_gl_drawable_gl_begin (osDrawable, me->osContext))
> {
> me->signal(&me->screenshot_complete);
> me->unlock();
> return FALSE;
> }
>
> // OPENGL DRAWING HERE
>
> gdk_gl_drawable_wait_gl(osDrawable);
> glReadBuffer(GL_FRONT);
> glReadPixels(me->xviewport,me->yviewport,me->widthvp,me->heightvp,
> GL_RGBA,GL_UNSIGNED_BYTE,me->screenshot_dest-
> >data[0]);
> me->signal(&me->screenshot_complete);
>
> me->unlock();
>
> gdk_gl_drawable_gl_end (osDrawable);
>
> return FALSE;
> }
>
> It appears that gdk_gl_drawable_gl_begin() is failing here. What
> could cause that? Both the context and drawable being passed are
> valid pointers. However, I did notice that
> gdk_gl_context_get_gl_drawable(me->osContext) returned NULL, which
> I thought was odd.
>
> I'm not positive that my glReadPixels() is valid either, but I
> want to get past this hurdle before worrying about that one.
>
> Any ideas?
> _______________________________________________
> gtkglext-list mailing list
> gtkglext-list@...
> http://mail.gnome.org/mailman/listinfo/gtkglext-list
>

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

GdkGLPixmap troubles

2009-08-26T11:46:58Z

I'm trying to allow an offscreen render to a pixmap to occur now, instead of trying to force an expose event while a window is offscreen like I was before.

I've looked over the example code in pixmap.c that comes with GtkGLExt, but my adaptation of it isn't working.

My configure-event handler:

gboolean reshapeGL(GtkWidget *widget, GdkEventConfigure *evnt, gpointer data)
{
GUIWindow* me = (GUIWindow*)data;
GdkGLContext *glcontext = gtk_widget_get_gl_context (widget);
GdkGLDrawable *gldrawable = gtk_widget_get_gl_drawable (widget);

assert(pthread_equal(me->mainthread, pthread_self()));
fprintf(stderr,"reshaping window %d, %d %d %d %d\n",me->window_id,evnt->x,evnt->y,evnt->width,evnt->height);

if (!gdk_gl_drawable_gl_begin (gldrawable, glcontext))
return FALSE;

me->lock();
me->xviewport = evnt->x;
me->widthvp = evnt->width;
me->yviewport = evnt->y;
me->heightvp = evnt->height;
glViewport(me->xviewport,me->yviewport,me->widthvp,me->heightvp);
me->unlock();

gdk_gl_drawable_gl_end (gldrawable);

if (me->osPixmap)
g_object_unref(me->osPixmap);
if (me->osContext)
gdk_gl_context_destroy(me->osContext);
me->osPixmap = gdk_pixmap_new (widget->window,
widget->allocation.width,
widget->allocation.height,
-1);
GdkGLConfig *glconfig = gdk_gl_config_new_by_mode (
GdkGLConfigMode(GDK_GL_MODE_RGB |
GDK_GL_MODE_SINGLE));
GdkGLDrawable *osDrawable = GDK_GL_DRAWABLE (
gdk_pixmap_set_gl_capability (me->osPixmap,
glconfig,
NULL));
me->osContext = gdk_gl_context_new (osDrawable,
glcontext,
FALSE,
GDK_GL_RGBA_TYPE);

return FALSE;
}

That all works fine so far as I can tell. There may be some issues with when exactly I'm supposed to unref something; the whole reference counting scheme is less than well-documented. However, I'm not concerned about that for now.

I also have this function, which is not linked to any particular event:

gboolean doTakeScreenshot(gpointer data)
{
GUIWindow *me = (GUIWindow *)data;

assert(pthread_equal(me->mainthread, pthread_self()));

me->lock();

GdkGLDrawable *osDrawable = GDK_GL_DRAWABLE(me->osPixmap);
if (!osDrawable || !me->osContext)
{
fprintf(stderr, "Warning, no offscreen pixbuf configured in aeGraphWindow::doTakeScreenshot.\n");
me->signal(&me->screenshot_complete);
me->unlock();
return FALSE;
}

if (!gdk_gl_drawable_gl_begin (osDrawable, me->osContext))
{
me->signal(&me->screenshot_complete);
me->unlock();
return FALSE;
}

// OPENGL DRAWING HERE

gdk_gl_drawable_wait_gl(osDrawable);
glReadBuffer(GL_FRONT);
glReadPixels(me->xviewport,me->yviewport,me->widthvp,me->heightvp,
GL_RGBA,GL_UNSIGNED_BYTE,me->screenshot_dest->data[0]);

me->signal(&me->screenshot_complete);

me->unlock();

gdk_gl_drawable_gl_end (osDrawable);

return FALSE;
}

It appears that gdk_gl_drawable_gl_begin() is failing here. What could cause that? Both the context and drawable being passed are valid pointers. However, I did notice that gdk_gl_context_get_gl_drawable(me->osContext) returned NULL, which I thought was odd.

I'm not positive that my glReadPixels() is valid either, but I want to get past this hurdle before worrying about that one.

Any ideas?
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Expose events and scissoring

2009-08-26T07:08:44Z

I'm still trying to create a "screenshot" mechanism for my GtkDrawingArea which will work even when the area isn't visible on-screen. I've made progress, but there's still a problem.

The GtkDrawingArea is OpenGL-enabled (cc'ing to the GtkGLExt list), and it's very difficult to draw OpenGL to an offscreen buffer without using OpenGL extensions, which I'd prefer to avoid. So my strategy is to do a normal expose event and just glReadPixels() the image from the GL_BACK buffer before the gdk_gl_drawable_swap_buffers() call.

The code works insofar as the expose event is triggered and the image written. However, the image which gets written often contains portions which aren't drawn properly. I'm presuming that the expose events aren't for the entire window (despite the fact that invalidated the whole thing), and that the rest is being silently scissored off somehow and left untouched.

I *could* try first doing a glReadPixels on the front buffer.....one hopes that anything not currently being exposed would be there. But that seems a bit dodgy. I'd prefer to have a way to force the entire drawing area to get drawn.

Anyone have any ideas?

The code is as follows:

me->screenshot_dest = img;//Flag to indicate the next expose should write to img
gtk_widget_queue_draw(me->drawarea);
GdkWindow *wind = gtk_widget_get_parent_window(me->drawarea);
GdkEventExpose expose;
expose.type = GDK_EXPOSE;
expose.window = wind;
expose.send_event = TRUE;
expose.area.x = 0;
expose.area.y = 0;
expose.area.width = 0;
expose.area.height = 0;
expose.region = NULL;
expose.count = 0;
GdkEvent e;
e.expose = expose;
gtk_widget_send_expose(me->drawarea,&e);
me->screenshot_dest = NULL;//done

I did wonder whether the fact that my expose event has 0 size would make a difference; I don't use the parameter in my function, but I really don't understand the mechanism well enough to say where else it might be relevant.
_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

Bug in shaders with Mea 7.5 devel driver with Intel 965GM chipset

2009-08-20T00:17:54Z

We develop an application displaying video thanks to OpenGL and GLSL shader.
The shader is used to process YUV to RGB space color conversion, and
image enhencements as edge enhencement.
OpenGL is used to process resizings - all kind of zooms.
This application was first developped to run on a PC with NVIDIA FX
Quadro GPU, Linux Fedora 10, Nvidia closed source driver
and was written in Java with the LWJGL OpenGL wrapper for Java.
We have test programs developped in C for GTK that use the gtkglext
OpenGL wrapper for GTK.
These programs have been tested with the following wrappers :
GLUT, gtkglext, gtkglarea and native GLX.
We want now to develop the same kind of application but for a low
consumption embedded platform.
So we want it to run on an Intel 965 GM chipset based hardware.
We are trying our test programs on this platform with Fedora 11, the
Intellinux 2D driver and the Mesa 3D 7.5-devel driver.
The drivers come from the Fedora repositories.
In this case the colors appear pink with the gtkglarea, gtkglext and
LWJGL wrappers.
The colors appear correct with GLUT and GLX.
After a lot of experiments I have changed the YUV to RGB conversion
shader by the following :

void main(void)
{
float r, g, b ;
r = 0.5 ; g = 0.5 ; b = 0.5 ;
gl_FragColor = vec4(r, g, b, 1.0) ;
}

I expected a grey display.
I get grey with GLUT and GLX but black with gtkglext and gtkglarea (not
tried on Java).

I change the shader for the fiollowing :

void main(void)
{
float r, g, b ;
r = 1.0 / 2.0 ; g = 1.0 / 2.0 ; b = 1.0 / 2.0 ;
gl_FragColor = vec4(r, g, b, 1.0) ;
}

I get grey for all wrappers.
Fun isn't it !!

So this leads to a walk around to the above problem.
In the YUV to RGB shader given, I can replace all the color space
conversion matrix coefficients constants by fractionnal constants. For
exemple
replace :
y = 1.1643 * (y - 0.0625) ;
by
y = 2.3286 / 2.0 * (y - 0.125 / 2.0 ) ;

And the colors are correct.

BUT, if I try to display a pure colors red green blue black pattern,
the final computed RGB values depends on the used wrapper.

It is expected that my shader, fed with the pattern, computes the
following r, g, b values :
R G B
blue 0 0 255
green 0 255 0
red 255 0 0
black 0 0 0
We get the following values with GLUT and GLX
R G B
blue 17 63 255
green 32 245 0
red 209 0 0
black 1 0 1
We get the following values with gtkglarea and gtkglext
R G B
blue 26 101 255
green 34 181 0
red 210 0 6
black 17 16 17

Conclusion :
- there is obviously a bug in way gtkglarea and gtkglext drive the shader
compilation.
- there is an extra processing in the OpenGL pipeline which is different
between the two kind of frameworks that modify the colors.

Have anybody an idea ?

I attach a tar file with the demo and its makefile.
This demo has been tested on an Lenovo R61 Laptop with Intel 965 GM
chipset and Fedora 11 (pink colors with gtkglext and gtkglarea)
and on a Dell M4400 laptop with Nvidia Quadro GPU with Nvidia closed
source driver and Fedora 10 (correct colors with all wrappers).

The demo is intended to display a red green blue checkerboard shaped
pattern.
GlxInfo data for the two above hardwares are attached in the tar file.
Just replace the xx.fs shader with the above shaders.

Thank you.

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list

yuvglxdemo.tar (1M) Download Attachment

GDK + GtkGLExt code example

2009-08-12T18:50:10Z

Hello. I have written this code example, for using GDK, GtkGLExt, and without using GTK+. It might be useful if you include it in the examples directory.

Here's ya link:

http://www.gtkforums.com/viewtopic.php?p=10586#10586

Here's ya code: (in case you don't believe me :D )

#include <glib.h>
#include <gdk/gdk.h>
#include <gdk/gdkgl.h>
#include <GL/gl.h>

#include "vec.h"

// uncomment this to enable blocking behavior
// that means that the cpu is used minimally (only when an event occurs)
// leave it disabled for full FPS (like most games)
//#define BLOCKING

GdkGLWindow *glwin = NULL;
GdkGLContext *glcontext = NULL;
#ifdef BLOCKING
GMainLoop *mainloop;
#else
gboolean done = false;
#endif
int width = 800, height = 600;

#define TILESIZE 32
int tilex, tiley;
#define XTILES 128
#define YTILES 128
unsigned char tiles[YTILES * XTILES];

void resize(int w, int h, GdkGLDrawable *drawable) {
if(gdk_gl_drawable_gl_begin(drawable, glcontext)) {
glViewport(0, 0, w, h);
width = w; height = h;
gdk_gl_drawable_gl_end(drawable);
}
}

void draw(GdkGLDrawable *drawable) {
if(!gdk_gl_drawable_gl_begin(drawable, glcontext)) return;

glClearColor(.1, .3, .5, 1.0);
glClear(GL_COLOR_BUFFER_BIT);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(0, width, height, 0, -1, 1); // this corresponds to the window coordinates 1:1, so we don't have to do any coordinate translation
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glBegin(GL_QUADS);
glColor3f(.9, .5, .2);
for(int x = 0; x < XTILES; x++) {
for(int y = 0; y < YTILES; y++) {
if(tiles[x + y * XTILES]) {
glVertex2i(x * TILESIZE, y * TILESIZE);
glVertex2i((x + 1) * TILESIZE, y * TILESIZE);
glVertex2i((x + 1) * TILESIZE, (y + 1) * TILESIZE);
glVertex2i(x * TILESIZE, (y + 1) * TILESIZE);
}
}
}
glEnd();
glBegin(GL_LINE_LOOP);
glVertex2i(tilex * TILESIZE, tiley * TILESIZE);
glVertex2i((tilex + 1) * TILESIZE, tiley * TILESIZE);
glVertex2i((tilex + 1) * TILESIZE, (tiley + 1) * TILESIZE);
glVertex2i(tilex * TILESIZE, (tiley + 1) * TILESIZE);
glEnd();

if(gdk_gl_drawable_is_double_buffered(drawable)) gdk_gl_drawable_swap_buffers(drawable);
else glFlush();

gdk_gl_drawable_gl_end(drawable);
}

static void toggle_tile(int tx, int ty) {
if(tx >= 0 && tx < XTILES && ty >= 0 && ty <= YTILES)
tiles[tx + XTILES * ty] ^= 1;
}
static void event_func(GdkEvent *ev, gpointer data) {
GdkGLDrawable *drawable = gdk_window_get_gl_drawable(ev->any.window);
switch(ev->type) {
#ifdef BLOCKING
case GDK_EXPOSE: // when in blocking mode, only redraw when the window is exposed (damaged)
draw(drawable);
break;
#endif
case GDK_DELETE:
#ifdef BLOCKING
g_main_loop_quit(mainloop);
#else
done = true;
#endif
break;
case GDK_MOTION_NOTIFY:
{
int tx = ev->motion.x / TILESIZE;
int ty = ev->motion.y / TILESIZE;
if(tilex != tx || tiley != ty) {
tilex = tx; tiley = ty;
if(ev->motion.state & GDK_BUTTON1_MASK) toggle_tile(tx, ty);
draw(drawable);
}
break;
}
case GDK_BUTTON_PRESS:
if(ev->button.button == 1) {
int tx = ev->button.x / TILESIZE;
int ty = ev->button.y / TILESIZE;
toggle_tile(tx, ty);
#ifdef BLOCKING
draw(drawable);
#endif
}
break;
case GDK_CONFIGURE:
resize(ev->configure.width, ev->configure.height, drawable);
#ifdef BLOCKING
draw(drawable);
#endif
break;
}
}

int main(int argc, char **argv) {
gdk_init(&argc, &argv);
gdk_gl_init(&argc, &argv);

int config_attributes[] = {
GDK_GL_DOUBLEBUFFER,
GDK_GL_RGBA,
GDK_GL_RED_SIZE, 1,
GDK_GL_GREEN_SIZE, 1,
GDK_GL_BLUE_SIZE, 1,
GDK_GL_DEPTH_SIZE, 12,
GDK_GL_ATTRIB_LIST_NONE
};
GdkGLConfig *glc = gdk_gl_config_new(config_attributes);

GdkWindowAttr attr;
attr.title = argv[0];
attr.event_mask = GDK_KEY_PRESS_MASK | GDK_BUTTON_PRESS_MASK | GDK_POINTER_MOTION_MASK | GDK_STRUCTURE_MASK | GDK_EXPOSURE_MASK;
attr.window_type = GDK_WINDOW_TOPLEVEL;
attr.wclass = GDK_INPUT_OUTPUT;
attr.width = width;
attr.height = height;
GdkWindow *win = gdk_window_new(NULL, &attr, 0);

gdk_window_show(win);

glwin = gdk_window_set_gl_capability(win, glc, NULL);
glcontext = gdk_gl_context_new(GDK_GL_DRAWABLE(glwin), NULL, true, GDK_GL_RGBA_TYPE);

#ifdef BLOCKING
gdk_event_handler_set(event_func, NULL, NULL); // this is used by GTK+ internally. We just use it for ourselves here

mainloop = g_main_loop_new(g_main_context_default(), FALSE);
g_main_loop_run(mainloop);
#else
while(!done) {
while(gdk_events_pending()) {
GdkEvent *ev = gdk_event_get();
if(ev) {
event_func(ev, NULL);
gdk_event_free(ev);
}
}
draw(GDK_GL_DRAWABLE(glwin));
}
#endif

gdk_gl_window_destroy(glwin);
gdk_window_destroy(win);

return 0;
}

_______________________________________________
gtkglext-list mailing list
gtkglext-list@...
http://mail.gnome.org/mailman/listinfo/gtkglext-list