Re: [GtkGLExt] Creating a new widget type vs. modifying an instance of an existing type

[Alif Wahid <alif wahid gmail com>]

I've had a look at the code. The GtkGLExt related part makes sense. 
However, I don't understand the full sequence of function calls inside 
the "expose_event" callback.

Usually the front and back buffers are swapped before exiting from the 
"expose_event" callback as we do in the example programs. In your case, 
the "redraw" method is called on the GtkGLView class. I presume that 
that method will subsequently call its fellow "swap_buffers" method?

Also, in the "post_redraw" method, you use the "gtk_widget_queue_draw" 
function. I recall sometime ago that Naofumi recommended and changed all 
the example programs to use the following two function calls instead 
after someone reported a bug of some sort.

/* Invalidate the whole window. */
gdk_window_invalidate_rect (widget->window, &widget->allocation, FALSE);

/* Update synchronously. */
gdk_window_process_updates (widget->window, FALSE);

It might be worth trying these as well.

I just get the feeling something funny is happening when you're using 
GtkPlug. I don't think we've ever tested GtkGLExt with GtkPlug. You 
definitely need someone with intricate knowledge of Mozilla and Gtk 
interactions and unfortunately that's not me. Sorry :(

Alif.


Braden McDaniel wrote:
> On Sat, 2005-01-01 at 02:14 +1300, Alif Wahid wrote:
>
> > Hi Braden,
> >
> >
> > > For various reasons I thought it better to change this approach to one
> > > where I simply use GtkDrawingArea directly and add GL capabilities and
> > > event callbacks to it when I construct it. This involved little more
> > > than moving some code around; and I had assumed that the user-visibible
> > > effect of this change would be nil. However, this appears to have had a
> > > significant impact on performance. Now when pressing a mouse button over
> > > the widget there is a significant delay before the widget response,
> > > where before it was virtually instantaneous. I'm also observing some
> > > crashes since making this change that suggest the event callbacks are
> > > now occurring on a different thread from before--surprising, but perhaps
> > > only because I don't know GTK well enough.
> >
> > Are you able to test your programming approach with code taken from one 
> > of the example programs that ship with GtkGLExt? The examples just 
> > create a standard GtkDrawingArea and add GL capability to it along with 
> > standard signal callbacks.
>
>
> Since the examples exhibit no such performance problems with that
> approach, I doubt it. I can't see that they're doing anything
> significantly different from what I'm doing.
>
>
> > A code snippet would help perhaps, to further clarify the problem you're 
> > having.
>
>
> I'm afraid anything I could provide as a snippet here would lack too
> much context. But the code is available if you'd like to take a look:
>
>         <http://sourceforge.net/project/showfiles.php?group_id=7151>
>
> openvrml-0.15.3 uses the approach that creates a new widget type.
> openvrm-0.15.4 uses the approach like the GtkGLExt examples. The code of
> interest is in "mozilla-plugin/src/openvrml.cpp".
>
> You can also see this via ViewCVS:
>
>         <http://cvs.sourceforge.net/viewcvs.py/openvrml/openvrml/mozilla-plugin/src/?only_with_tag=OpenVRML-0_15_3-RELEASE>
>         <http://cvs.sourceforge.net/viewcvs.py/openvrml/openvrml/mozilla-plugin/src/?only_with_tag=OpenVRML-0_15_4-RELEASE>
>
> > I cannot see anything wrong with your approach since that's the 
> > approach we took when writing all the example programs. I suspect the 
> > problems are occuring may be because of the multithreaded nature of 
> > Mozilla and how it loads plugin modules.
>
>
> I suspect you're right. Though, the multithreading issues here seem to
> have to do with the GUI rather than actually loading the module. (I'm
> over that hurdle... I hope.) I guess I need to find someone intimately
> familiar with how Mozilla uses GTK.
>
> BTW, do you know if Naofumi is still active on this project?