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



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?




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]