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

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?


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>
<>                    Jabber: <braden jabber org>

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