Re: (severe) performance issues

["Matt Fischer" <mattfischer84 gmail com>]

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