Re: (severe) performance issues

["David J. Andruczyk" <djandruczyk yahoo com>]

I did further testing . Packing the label with EXPAND
flags has ZERO change, as does restricting its size
with a set_usize.  It still causes high cpu usage.

I've expended enough effort on this thorn in my side,
and have relegated to using GTK entries instead. (they
look crappy (the box/border makes things too "busy"
compared to the clean label), as I didn't want to have
to go thru the trouble of drawing a  layout and having
to worry about configure/expose events with manual
drawing.


--- Matt Fischer <mattfischer84 gmail com> wrote:

> On 3/30/07, Olaf FrÄ?czyk <olaf cbk poznan pl>
> wrote:
> 
> > On Thu, 2007-03-29 at 13:58 -0700, David J.
> Andruczyk wrote:
> > > --- David Neèas (Yeti) <yeti physics muni cz>
> wrote:
> > > > Updating textual information 30x a second
> (2007-March/msg00116)
> > > > does not make any sense though.
> > > >
> > > > Yeti
> > >
> > > It does when you're monitoring a realtime
> datalogging system, and
> > > don't want to have gaps  or slow response in the
> updates. (there
> > > are also graphical monitors as well,  but the
> text is there for a
> > > precise reading)
> > Wow,
> >
> > I assume that you have some military brain wiring
> from XXX century.
> > Getting precise reading 30 times per second is
> quite fast ;)
> >
> > BTW. It doesn't mean that GTK shouldn't be faster.
> It should :)
> 
> 
> So we've established a difference in opinion over
> the best way to design
> this UI.  That is, however, not why this post was
> originally made.  He's
> made a decision about how to design his UI, and he's
> simply looking for help
> implementing it.  There might be some valid
> arguments why this design could
> be improved, but the topic at hand is nuts and
> bolts.  Further, we've
> established via small test programs that GTK is in
> general capable of the
> desired refresh rates, so it's simply a matter of
> implementing it correctly.
> 
> The consensus seems to be that the actual slowness
> is due to the fact that
> each update to the Label causes a size
> re-negotiation, which due to the
> particular widget configuration in use, causes a
> cascade across the entire
> window.  This could easily include some widget which
> is known to be slow
> laying out, but was not thought to be a problem
> because it was never
> intended to update so fast.  This theory would seem
> to be backed up by the
> fact that performance is acceptable when using a
> GtkEntry, which lacks
> dynamic sizing.
> 
> If this is the case, often a trivial change to the
> structure of the widget
> hierarchy can stem the problem, namely by preventing
> an update to the
> label's size from filtering all the way back up to
> the rest of the layout.
> A screenshot would be helpful here--what, in
> general, is this supposed to
> look like?  The solutions that come to my mind are
> 1) put the label in a
> GtkFixed, which doesn't transmit size changes in its
> children upwards, or 2)
> if the label is in some sort of Box or Table
> control, be sure that it was
> added with EXPAND flags, causing the widget to be
> forcibly expanded to fill
> the entire area (you can use the Label's internal
> alignment commands or an
> actual GtkAlignment to fine-tune its position within
> this area.)  If this is
> done, then setting the text won't update the
> widget's size, thus preventing
> the cascade.
> 
> Finally, if all else fails, you can take the course
> of action mentioned by
> Paul and David, and manually draw the text into
> place.  I too have mainly
> used Gtkmm (which makes this sort of thing very
> easy), but if I understand
> the general GTK workflow correctly, this should be
> quite trivial in Gtk+
> itself as well.  Simply make an empty widget with a
> fixed size (set_usize()
> I believe is the method you want), and hook a signal
> handler to its expose
> event.  In the handler, construct a Pango layout
> containing the desired
> text, and draw it into place.  You can even issue a
> gdk_window_process_updates() call inside of whatever
> code updates the value,
> to force a synchronous redraw of the label.  Plus,
> the size request never
> changes, so the current problems disappear.  Let me
> reiterate that,
> depending on your widget hierarchy, you can likely
> get away without doing
> this, using one of the methods listed above, but
> this should provide a good
> fallback.
> 
> As an aside, the sort of finger-pointing that's been
> going on here is really
> unnecessary.  Having not seen his UI design, none of
> us is in a position to
> judge how it should be set up, and certainly not to
> use that as a reason not
> to find a technical solution to the problem at hand.
>  Conversely, blaming
> the toolkit because it doesn't implement the
> behavior you think it should is
> not productive either.  The GtkLabel is not broken. 
> It behaves as it does
> precisely because that is the most common case for
> its use.  The toolkit
> provides several methods to circumvent this behavior
> for use in applications
> such as yours, and implementing any one of them will
> be far quicker than
> demanding a new, very special-case mode of behavior
> be added into a base
> widget, integrated into the master paradigm for the
> library, and tested both
> for consistency and to ensure behavior on older apps
> doesn't change,
> especially when such demands are made so abruptly,
> and without an offer to
> help do any of the legwork.  Gtk+ is flexible enough
> to do just about
> anything you want it to, if you are willing to step
> back and consider some
> of the options which are already present in its
> framework.
> 
> --Matt
> > _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
> 


-- David J. Andruczyk


 
____________________________________________________________________________________
Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097