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

[Braden McDaniel <braden endoframe com>]

On Sat, 2005-01-01 at 18:57 +1300, Alif Wahid wrote:
> > Of note is that I'm not quite using GtkPlug in the "normal" sense. That
> > is, it's main job (or so I gather) is to support an out-of-process
> > widget. While I think it *should* be perfectly usable in the
> > configuration I'm using it, it's entirely possible that other code
> > interacting with the GtkPlug may not be fully prepared for the
> > repercussions of it supporting an in-process widget. It may be that I'd
> > save myself a lot of grief by making my plug-in out-of-process. I didn't
> > do that in the first place in the hope that I could avoid the grief of
> > IPC. Perhaps I did not choose my poison wisely.
> 
> I was definitely under the impression that GtkPlug is supposed to be 
> used with widgets in another process as explained in the ref docs. IPC 
> would be a pain for sure in that case. When you derived a new widget, 
> things worked fine I presume? Even with GtkPlug used for an in-process 
> widget?

Yes.

I've moved it out-of-process now, though, and performance is acceptable.
I'm not sure it's as good as it was with the derived widget, so I may
experiment with reverting to that model in the out-of-process setup.

However, I only get acceptable performance when requesting a redraw with
gtk_widget_queue_draw; when I use the gdk_window_invalidate_rect,
gdk_window_process_updates pair, I get a delay characteristic of what I
was seeing when I used *both* of these methods in the in-process setup.
This delay isn't tied to running in the GtkPlug context; it happens if I
run my viewer in its own GtkWindow as well.

If you'd like to look at the code, I'll probably have it checked into
CVS in the next day or two.

-- 
Braden McDaniel                           e-mail: <braden endoframe com>
<http://endoframe.com>                    Jabber: <braden jabber org>