Re: [GtkGLExt-develop] performance issues with gtkglext (fwd)

[Drew Hess <dhess ilm com>]

Hi all,

Per my previous email, I'm still having performance issues when redrawing 
gtk adjustment objects.  Here's the latest email between Naofumi and me, 
in case anyone on this list has ideas....

thanks

-dwh-


---------- Forwarded message ----------
Date: Tue, 4 Nov 2003 12:50:29 -0800 (PST)
From: Drew Hess <dhess ilm com>
To: Naofumi Yasufuku <naofumi users sourceforge net>
Cc: gtkglext-develop lists sourceforge net
Subject: Re: [GtkGLExt-develop] performance issues with gtkglext


Thanks.  I tried updating the entire container window, but that doesn't 
make any difference in performance.

As an experiment, I removed the HScale widget from my hbox, so all I'm
left with is a label.  I call set_text on the label once every second.  
When I do this, synchronously redrawing the entire container window still
costs me 1-3 fps.  When I only redraw the GL child window synchronously,
performance is fine.

In the couple of cases I was looking at, the screen area of the hbox is 
probably only 3-5% of the screen area of the entire window, so the cost 
for redrawing it is disproportionate to its area.


-dwh-


On Tue, 4 Nov 2003, Naofumi Yasufuku wrote:

> At Tue, 4 Nov 2003 01:41:36 -0800 (PST),
> Drew Hess wrote:
> > Well, I sort of got this working.  I can invalidate the GL rect and call 
> > its Gdk::Window::process_update(), but for some reason get_window () on my 
> > HScale widget always returns a Glib::RefPtr of 0!  Not sure what's going 
> > on there.  So for now I'm still doing a queue_draw on the HScale widget, 
> > and the performance is still about 15fps.  
> >
> > (When I don't draw the HScale widget, the synchronous expose event on the
> > GL window does give me more precise frame rates, so I'll keep that change,
> > at least.  Thanks for the tip.)
> >
> > While playing around I found that using Gtk::PACK_SHRINK when packing the
> > HScale widget into the HBox boosts the performance to 19fps, so at least
> > part of the slowdown is directly proportional to the width in pixels of
> > the HScale widget.  So I could try to do something clever like approximate
> > the location of the slider and invalidate a small rect around it.  Still,
> > losing 3fps just to call Gtk::Range::set_value() 24 times a second seems
> > extreme.
> >
> > Any other ideas?
>
> GtkRange (base class of Scale widgets) doesn't have own window. It
> paints on parent window directly. Anyway, it seems odd that
> get_window() returns 0. If a widget doesn't have own window,
> widget->window will be set to its parent window...
>
> I think you might parhaps have to call process_update() against the
> top-level container window with TRUE update_children argument. It will
> update child GL window synchronously...
>
> Regards,
> --Naofumi
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> GtkGLExt-develop mailing list
> GtkGLExt-develop lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/gtkglext-develop