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@xxxxxxxxx> wrote: > On 3/30/07, Olaf FrÄ?czyk <olaf@xxxxxxxxxxxxx> > wrote: > > > On Thu, 2007-03-29 at 13:58 -0700, David J. > Andruczyk wrote: > > > --- David Neèas (Yeti) <yeti@xxxxxxxxxxxxxxx> > 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@xxxxxxxxx > 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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
