Re: (severe) performance issues
> If that's the case, then perhaps you might be interested in the Java > bindings for GTK and GNOME, java-gnome. See > http://java-gnome.sourceforge.net/ Well I did some projects with earlier versions of java-gnome and the api is really fine. However apps written with it have of course the same performance problems as other native GTK applications. lg Clemens ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Wed, 2007-08-15 at 10:41 +0200, Clemens Eisserer wrote: > because my home-language is Java ;) If that's the case, then perhaps you might be interested in the Java bindings for GTK and GNOME, java-gnome. See http://java-gnome.sourceforge.net/ Yes, of course, it still talks through to the underlying GNOME libraries (that is, after all our whole point) so is subject to all the underlying performance questions. We have, however, been pleasantly surprised in general responsiveness, and of course you can stay in Java for everything else you're up to. Hackers who understand the GNOME stack at a deep level and who are also Java people are a rare breed. The new bindings are quite young, any contribution would be more than welcome. AfC Sydney (sorry to plug, but it seemed appropriate. Not trying to derail the thread. Follow ups to the java-gnome mailing list) -- Andrew Frederick Cowie We are an operations engineering consultancy focusing on strategy, organizational architecture, systems review, and change management procedures: enabling successful use of open source in mission critical enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London signature.asc Description: This is a digitally signed message part ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
Hi David, > Got any opinions on Trolltech's QT 4.x ? (Cross > platformness is key for me) > I've been debating dumping GTK+ altogether and going > to QT for a ground up rewrite of my app because of > these performance issues. (which are atrociously bad > when running certain pixmap themes, I'm seeing > slowdowns as much as 2-4x additional on top of > it'scurrent issues). Yes, QT is in my opinion quite mature and well optimized, but well ... expensive as hell if you don't do GPL'ed stuff. Some time ago I did some tests against QT-3.? and it was surprisingly fast, what I've heard QT-4 is again 20% faster. I don't know how much Java is suited for your task, but some benchmarks I did also showed very good UI performance for applications writting using Java/Swing. Fox is also very fast, but looks quite old: http://fox-toolkit.org/ > C++ will take some getting used to (slightly different > concepts, but I think it would be better overall). Well I don't like both for application development, maybe because my home-language is java ;) But to be honest I guess its way better (also for the generated code) to have OO concepts in the language itself, than to emulate it like GLib does. lg Clemens ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
Hi David, > I did my part by SUBMITTING BUG REPORTS, several in fact.. > I'm an not a GTK+ wizard, nor do I know all the intricacies about > how it renders. hence I GAVE them the information ,described the > problems, and it was tossed out. You should better not post/ask/report about performance problems with GTK+. For some unknown reason many developers don't talk about this, its some kind of taboo. So be everybody's friend here just send a message to the list saying that GTK is wonderful and fast. A lot of GTK+ performance problems accumulate: * GLib's object system: Written in plain C. A simply typecast in Java costs typically 1cycle (for classes) or about 100 in the worst case (for some special cases with interfaces). Look at GLibs typecast code and you'll understand ... countless cycles :-/. I've seen code spending 3% of time in casts (oprifile)! The typecast-stuff is just an example, but I don't think its a lot different in other areas. * No performance monitoring: Unlike many other projects GTK+ does not have any performance regression testing. Small regressions accumulate over time and nobody notices. * Unoptimized drawing: GTK allocates a pixmap for every sub-window which is repainted (typically about 100's for larger apps), draws into it a singly time and throws it away again. Not funny. * Typical performance bugs: Like the one you are seeing. Nobody tries to fix, most work arround, others produce slow apps. lg Clemens ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 4/4/07, David J. Andruczyk <[EMAIL PROTECTED]> wrote: > Nope. that tab is the ONLY one that is updating, and > I have code in place so if that tab is NOT active, it > doesn't even update it at ALL. I have tested this > VERY thoroughly.. By commenting out ONE LINE in my > code that updates the 22 labels on that tab, cpu usage > goes from "high" to zero. Right now it does NOT even > update them all. There is logic in place to reduce > the number of updates. (it checks based on last update > time, the number of times it's skipped, and a "delta" > from last value (if it changes too much it forces and > update) > > I have yet to try placing the label into a GtkFixed > yet as per another users suggestion. > I see. I STAND corrected. MAYBE you should try as (one of the) Paul DAVIES suggested and write a custom label that doesn't propagate the size requests. Shouldn't be too hard. iain ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
Nope. that tab is the ONLY one that is updating, and I have code in place so if that tab is NOT active, it doesn't even update it at ALL. I have tested this VERY thoroughly.. By commenting out ONE LINE in my code that updates the 22 labels on that tab, cpu usage goes from "high" to zero. Right now it does NOT even update them all. There is logic in place to reduce the number of updates. (it checks based on last update time, the number of times it's skipped, and a "delta" from last value (if it changes too much it forces and update) I have yet to try placing the label into a GtkFixed yet as per another users suggestion. --- Iain * <[EMAIL PROTECTED]> wrote: > On 4/3/07, David J. Andruczyk > <[EMAIL PROTECTED]> wrote: > > > > http://megatunix.sourceforge.net/screenshots/images/runtime-display-tab.png > > Just wondering, and not in anyway trying to dispute > that GtkLabel > could be better, but are there lots of labels on all > those hidden > pages also being updated 30times a second? If there > are, then I'm not > really surprised that there's severe performance > issues. You probably > want to listen for the page change signal and turn > off updating for > the pages that aren't visible. I bet once you do > that, you'll have no > performance issues whatsoever. > > iain > -- David J. Andruczyk 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 4/3/07, David J. Andruczyk <[EMAIL PROTECTED]> wrote: > http://megatunix.sourceforge.net/screenshots/images/runtime-display-tab.png Just wondering, and not in anyway trying to dispute that GtkLabel could be better, but are there lots of labels on all those hidden pages also being updated 30times a second? If there are, then I'm not really surprised that there's severe performance issues. You probably want to listen for the page change signal and turn off updating for the pages that aren't visible. I bet once you do that, you'll have no performance issues whatsoever. iain ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
Just tried the test again on the following: * Athlon 1.1 GHz * gtk 2.10.8 * nVidia GeForce 2 MX 400 * Same defaults and I see about 99% CPU usage, shared by XOrg and the executable itself, in about a 2-1 ratio. I'm not sure if we're proving that the original post had a point or that we have a lot of hardware, some of it good, some of it crap ;) --- [EMAIL PROTECTED] wrote: > On 4/3/07, Bobby Jack <[EMAIL PROTECTED]> > wrote: > > My results with the following: > > > >* Intel P4 3.2 GHz > >* Onboard graphics controller (this may well be > the > > limitation) > >* GTK 2.10.8 > >* Test program defaults (50 labels, 100 FPS) > > > > are CPU usage consistently above 50%. I can try to > > reproduce this on another machine (much slower > CPU, > > better - although still quite old - nvidia > graphics > > card) if that would be useful. > > That's interesting. I just tried on my laptop (1.8 > GHz PM, ATI > mobility, gtk2.10) and I get about 40% CPU usage, > which is more than > I'd expect. I'll try building gtk2.10 on my work > machine tomorrow and > see if 2.8 -> 2.10 makes much difference. > > John > It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 4/3/07, Bobby Jack <[EMAIL PROTECTED]> wrote: > My results with the following: > >* Intel P4 3.2 GHz >* Onboard graphics controller (this may well be the > limitation) >* GTK 2.10.8 >* Test program defaults (50 labels, 100 FPS) > > are CPU usage consistently above 50%. I can try to > reproduce this on another machine (much slower CPU, > better - although still quite old - nvidia graphics > card) if that would be useful. That's interesting. I just tried on my laptop (1.8 GHz PM, ATI mobility, gtk2.10) and I get about 40% CPU usage, which is more than I'd expect. I'll try building gtk2.10 on my work machine tomorrow and see if 2.8 -> 2.10 makes much difference. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
My results with the following: * Intel P4 3.2 GHz * Onboard graphics controller (this may well be the limitation) * GTK 2.10.8 * Test program defaults (50 labels, 100 FPS) are CPU usage consistently above 50%. I can try to reproduce this on another machine (much slower CPU, better - although still quite old - nvidia graphics card) if that would be useful. --- [EMAIL PROTECTED] wrote: > Hi Bobby, > > On 4/3/07, Bobby Jack <[EMAIL PROTECTED]> > wrote: > > Can you include some details as to how you > gathered > > these metrics? I'm seeing very different results > from > > your test program, although I'm just eyeballing > top so > > I'd like to use whatever method you did. > > That's all I did as well. If I compile and run the > test program, it > (almost) never appears on top. If I change it to 100 > labels at 100 Hz, > I see just over 1% CPU (from memory). > > Do you see something very different? What X server / > graphics card / > CPU / gtk do you have? My card is a very modest > nvidia (less than 100 > ukp), though I do have a fast CPU. > > John > Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
Hi Bobby, On 4/3/07, Bobby Jack <[EMAIL PROTECTED]> wrote: > Can you include some details as to how you gathered > these metrics? I'm seeing very different results from > your test program, although I'm just eyeballing top so > I'd like to use whatever method you did. That's all I did as well. If I compile and run the test program, it (almost) never appears on top. If I change it to 100 labels at 100 Hz, I see just over 1% CPU (from memory). Do you see something very different? What X server / graphics card / CPU / gtk do you have? My card is a very modest nvidia (less than 100 ukp), though I do have a fast CPU. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
In my case, my display is NOT so simple. my label is
packed into an hbox (with EXPAND) in the middle of
another fixed (non updating) label, and a progress bar
(which is part of a size group to keep the pbars all a
consistent size). Multiple instances of these hbox's
are packed into a table.
http://megatunix.sourceforge.net/screenshots/images/runtime-display-tab.png
--- Bobby Jack <[EMAIL PROTECTED]> wrote:
>
>
> Can you include some details as to how you gathered
> these metrics? I'm seeing very different results
> from
> your test program, although I'm just eyeballing top
> so
> I'd like to use whatever method you did.
>
> - Bobby
>
> --- [EMAIL PROTECTED] wrote:
>
> > Hi David,
> >
> > On 3/26/07, David J. Andruczyk
> > <[EMAIL PROTECTED]> wrote:
> > > I would NOT expect updating approx 10 labels
> > perhaps 5-10 times per
> > > second (ie. when data chages) on a 1.8Ghz
> machine
> > be so cpu hungry.
> >
> > I made a tiny test program. This updates 50 labels
> > at 100Hz with less
> > than 1% CPU on my machine.
> >
> > --
> > /* compile with
> > * gcc -Wall try16.c `pkg-config gtk+-2.0
> > --cflags --libs`
> > */
> >
> > #include
> > #include
> >
> > const int NUM_LABELS = 50;
> > const int FPS = 100;
> >
> > gboolean
> > update_labels (GtkWidget * label[])
> > {
> > int i;
> >
> > for (i = 0; i < NUM_LABELS; i++)
> > {
> > char buf[256];
> >
> > snprintf (buf, 256, "%d", rand ());
> > gtk_label_set_text (GTK_LABEL (label[i]),
> > buf);
> > }
> >
> > return TRUE;
> > }
> >
> > int
> > main (int argc, char **argv)
> > {
> > GtkWidget *label[NUM_LABELS];
> > GtkWidget *win, *box;
> > int i;
> >
> > gtk_init (&argc, &argv);
> > win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> > g_signal_connect (win, "destroy", G_CALLBACK
> > (gtk_main_quit), NULL);
> >
> > box = gtk_vbox_new (FALSE, 0);
> > gtk_container_add (GTK_CONTAINER (win), box);
> >
> > for (i = 0; i < NUM_LABELS; i++)
> > {
> > label[i] = gtk_label_new (NULL);
> > gtk_box_pack_start (GTK_BOX (box), label[i],
> > TRUE, TRUE, 0);
> > }
> >
> > g_timeout_add (1000 / FPS, (GSourceFunc)
> > update_labels, label);
> >
> > gtk_widget_show_all (win);
> >
> > gtk_main ();
> >
> > return 0;
> > }
> > -
> >
> > I have Dapper still on my machine (gtk 2.8, amd64
> > 2.7 GHz) which might
> > make some difference I guess. Though I think Pango
> > has actually sped
> > up in 2.10.
> >
> > I wonder if another reason might be resizing?
> > Setting a label's text
> > can cause the label to change size, which might be
> > forcing some
> > (large?) chunk of your interface to resize too.
> You
> > could try using
> > gtk_widget_set_size_request() on your labels to
> make
> > them a fixed
> > size.
> >
> > John
> > ___
> > gtk-list mailing list
> > gtk-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/gtk-list
> >
>
>
>
>
>
> Don't pick lemons.
> See all the new 2007 cars at Yahoo! Autos.
> http://autos.yahoo.com/new_cars.html
>
-- David J. Andruczyk
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
John,
Can you include some details as to how you gathered
these metrics? I'm seeing very different results from
your test program, although I'm just eyeballing top so
I'd like to use whatever method you did.
- Bobby
--- [EMAIL PROTECTED] wrote:
> Hi David,
>
> On 3/26/07, David J. Andruczyk
> <[EMAIL PROTECTED]> wrote:
> > I would NOT expect updating approx 10 labels
> perhaps 5-10 times per
> > second (ie. when data chages) on a 1.8Ghz machine
> be so cpu hungry.
>
> I made a tiny test program. This updates 50 labels
> at 100Hz with less
> than 1% CPU on my machine.
>
> --
> /* compile with
> * gcc -Wall try16.c `pkg-config gtk+-2.0
> --cflags --libs`
> */
>
> #include
> #include
>
> const int NUM_LABELS = 50;
> const int FPS = 100;
>
> gboolean
> update_labels (GtkWidget * label[])
> {
> int i;
>
> for (i = 0; i < NUM_LABELS; i++)
> {
> char buf[256];
>
> snprintf (buf, 256, "%d", rand ());
> gtk_label_set_text (GTK_LABEL (label[i]),
> buf);
> }
>
> return TRUE;
> }
>
> int
> main (int argc, char **argv)
> {
> GtkWidget *label[NUM_LABELS];
> GtkWidget *win, *box;
> int i;
>
> gtk_init (&argc, &argv);
> win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> g_signal_connect (win, "destroy", G_CALLBACK
> (gtk_main_quit), NULL);
>
> box = gtk_vbox_new (FALSE, 0);
> gtk_container_add (GTK_CONTAINER (win), box);
>
> for (i = 0; i < NUM_LABELS; i++)
> {
> label[i] = gtk_label_new (NULL);
> gtk_box_pack_start (GTK_BOX (box), label[i],
> TRUE, TRUE, 0);
> }
>
> g_timeout_add (1000 / FPS, (GSourceFunc)
> update_labels, label);
>
> gtk_widget_show_all (win);
>
> gtk_main ();
>
> return 0;
> }
> -
>
> I have Dapper still on my machine (gtk 2.8, amd64
> 2.7 GHz) which might
> make some difference I guess. Though I think Pango
> has actually sped
> up in 2.10.
>
> I wonder if another reason might be resizing?
> Setting a label's text
> can cause the label to change size, which might be
> forcing some
> (large?) chunk of your interface to resize too. You
> could try using
> gtk_widget_set_size_request() on your labels to make
> them a fixed
> size.
>
> John
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Mon, 2007-04-02 at 08:56 -0700, David J. Andruczyk wrote: > 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. Did you ever try the suggestion of putting the label in a GtkFixed container? Seems like that would be the best workaround for you. GtkFixed will only experience the configure event (and subsequent cascade of adjustments) when it is first displayed. After that you can update the label to your heart's content without setting of a cascade of configure events. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
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 <[EMAIL PROTECTED]> wrote: > On 3/30/07, Olaf FrÄ czyk <[EMAIL PROTECTED]> > wrote: > > > On Thu, 2007-03-29 at 13:58 -0700, David J. > Andruczyk wrote: > > > --- David Neèas (Yeti) <[EMAIL PROTECTED]> > 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
Re: (severe) performance issues
On 3/30/07, Olaf Frączyk <[EMAIL PROTECTED]> wrote: On Thu, 2007-03-29 at 13:58 -0700, David J. Andruczyk wrote: > --- David Neèas (Yeti) <[EMAIL PROTECTED]> 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
Re: (severe) performance issues
In terms of adding functionality to the widget itself to handle this very contentious situation, whynot something like: 1) add an attribute to the widget named, say, GTK_LABEL_NO_SIZE_REDUCTION (or whatever) 2) with this attribute set, the label will only resize if the new label results in a size larger than the currently known maximum, i.e., the maximum size of all previously set labels for any given invocation of the program. It would seem to me this would be fairly straightforward to implement, only need to save the current max size and test against it when the label is re-set. Not sure, but I would bet this would solve the original poster's problem (while the required change to the widget would, as well, not be so onerous?). richard On Mar 30, 2007, at 1:34 PM, [EMAIL PROTECTED] wrote: > On 3/30/07, Paul Davis <[EMAIL PROTECTED]> wrote: >> So I've spent about 15 minutes going through software on this >> computer >> looking through different windows trying to find an example of a >> label >> that changes to convey some interesting piece of information. I can't >> find any. > > I don't know if this is what you mean, but I have an example in my > image processing application. > > Image windows have an optional status bar which shows width, height, > etc. and also current mouse position in x/y image coordinates, and the > value of the pixel under the mouse. > > http://cima.ng-london.org.uk/~john/statusbar.png > > The labels showing x/y/value have to be fixed in size so they don't > jiggle left-right as you move the mouse around. I do this by calling > gtk_widget_set_size_request() on them after measuring the size of the > largest value I can show in the right font. > > It seems that calling gtk_widget_set_size_request() on a label locks > the size, but doesn't stop the label from triggering a resize when the > label's content next changes. > > Maybe this is somthing that could be changed without breaking > anything? > > John > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 13:58 -0700, David J. Andruczyk wrote: > --- David Neèas (Yeti) <[EMAIL PROTECTED]> 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 :) Regards, Olaf -- Olaf Frączyk <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 3/30/07, Paul Davis <[EMAIL PROTECTED]> wrote: > So I've spent about 15 minutes going through software on this computer > looking through different windows trying to find an example of a label > that changes to convey some interesting piece of information. I can't > find any. I don't know if this is what you mean, but I have an example in my image processing application. Image windows have an optional status bar which shows width, height, etc. and also current mouse position in x/y image coordinates, and the value of the pixel under the mouse. http://cima.ng-london.org.uk/~john/statusbar.png The labels showing x/y/value have to be fixed in size so they don't jiggle left-right as you move the mouse around. I do this by calling gtk_widget_set_size_request() on them after measuring the size of the largest value I can show in the right font. It seems that calling gtk_widget_set_size_request() on a label locks the size, but doesn't stop the label from triggering a resize when the label's content next changes. Maybe this is somthing that could be changed without breaking anything? John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 3/30/07, Murray Cumming <[EMAIL PROTECTED]> wrote: > On Thu, 2007-03-29 at 22:02 -0500, Paul Davis wrote: > > To me, a GtkLabel is a 'label' (get it?). A label shouldn't change. It > > tells the user what a given piece of information is. > > That doesn't make much sense to me. Information can change over time, > and it's normal to show this to the user. > > If there's problem with showing changing information, at a rate that the > user can perceive, then maybe that can be dealt with as an option. I'd > be surprised if that requires an extra widget, though ABI compatibility > might convievably make that necessary. > > -- > Murray Cumming > [EMAIL PROTECTED] > www.murrayc.com > www.openismus.com > > I've tried about 5 times to reword what I mean but nothing is comming to me. So I've spent about 15 minutes going through software on this computer looking through different windows trying to find an example of a label that changes to convey some interesting piece of information. I can't find any. The only example I can think of is from my bittorrent client. And its got a fairly horrible UI. Note that we're describing a situation where the data thats changing is interesting precisely because its changing. The change in the data is as interesting or more interesting than the value itself. I just thought of a situation where you might want to use a table of labels to describe some properties of an object. Obviously, for different objects, the labels would change. This isn't quite what I'm thinking of. (There are always exceptions to the rule. There's probably even a rule thats an exception to the exceptions rule which provides us with an intersting paradox...) Anyway, all I can really say in conclusion is that when I think of good UI design, I don't think table of rapidly changing values. I think fancy graphics that show important information at a glance along with some method of reading a precise value. Paul Davis ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 22:02 -0500, Paul Davis wrote: > To me, a GtkLabel is a 'label' (get it?). A label shouldn't change. It > tells the user what a given piece of information is. That doesn't make much sense to me. Information can change over time, and it's normal to show this to the user. If there's problem with showing changing information, at a rate that the user can perceive, then maybe that can be dealt with as an option. I'd be surprised if that requires an extra widget, though ABI compatibility might convievably make that necessary. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 3/29/07, Robert Pearce <[EMAIL PROTECTED]> wrote: > On Thu, 29 Mar 2007 13:58:51 -0700 (PDT) > "David J. Andruczyk" <[EMAIL PROTECTED]> wrote: > > > > > 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) > > > No, it doesn't. No, it absolutely doesn't. Who the £%$% do you think is > watching this? Because you seem to have forgotten (along with your manners) > the FIRST RULE OF GUI DESIGN : > > If it's not USEFUL to the USER it's WRONG. > > I use high speed data loggers. I would not want your "feature". > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > I've been following this thread for a bit and thought I might make a couple points that I haven't really seen yet. First, there's been talk of the efficiency of GtkLabel vs. GtkEntry, but not of the conceptual difference as far as I've read. To me, a GtkLabel is a 'label' (get it?). A label shouldn't change. It tells the user what a given piece of information is. A GtkEntry contains a value. A value is expected to change. As to making an entry look like a label, I don't really understand why thats necessary, but thats a design decision and one I don't quite understand at that. My other point of contention is the discussion on how fast to update these widgets. Some of the posters have immediately said thats too fast. If you find yourself among this group, ask yourself one question, "Would I want to fly in a plane where the instruments were updated any slower?" I sure as hell wouldn't. Granted thats reductio ad absurum, but I think it gets the point across. Anyway, just my thoughts. Paul Davis (don't get confused, there are two of us). ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 22:49 +0100, Robert Pearce wrote: > On Thu, 29 Mar 2007 13:58:51 -0700 (PDT) > "David J. Andruczyk" <[EMAIL PROTECTED]> wrote: > > > > > 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) > > > No, it doesn't. No, it absolutely doesn't. Who the £%$% do you think is > watching this? Because you seem to have forgotten (along with your manners) > the FIRST RULE OF GUI DESIGN : > > If it's not USEFUL to the USER it's WRONG. > > I use high speed data loggers. I would not want your "feature". sometimes, the 30Hz "signal" transmitted to the user by the simple fact that the text is rapidly changing is actually very useful. 30fps is roughly the level needed to avoid visual perception of discontinuity - one could argue that 10Hz or 40Hz might be better for a visual "image" that isn't ever going to be continuous anyway. either way, its not clear to me that changing text so fast that it cannot be read is WRONG. there are certainly many cases where its counter productive. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 29 Mar 2007 13:58:51 -0700 (PDT) "David J. Andruczyk" <[EMAIL PROTECTED]> wrote: > > 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) > No, it doesn't. No, it absolutely doesn't. Who the £%$% do you think is watching this? Because you seem to have forgotten (along with your manners) the FIRST RULE OF GUI DESIGN : If it's not USEFUL to the USER it's WRONG. I use high speed data loggers. I would not want your "feature". ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 13:58 -0700, David J. Andruczyk 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) But you can't perceive changes in text 30 times in a second, so there's no point in showing that to a human. If you want to log the details for later (slower) perusal then you can do that, independently of any GtkLabel. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
--- David Neèas (Yeti) <[EMAIL PROTECTED]> wrote: > On Thu, Mar 29, 2007 at 12:43:20PM -0700, David J. Andruczyk > wrote: > > > > since there is NO other wisget that can > > be used to display rapidlychanging text. > > Most widgets can do it. Just do gdk_draw_layout() on > whatever you want. > > > (it's a textual display > > for a realtime datalogger, so fast updating is wanted) > > 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) -- David J. Andruczyk Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 22:27 +0200, David Nečas (Yeti) wrote: > On Thu, Mar 29, 2007 at 12:43:20PM -0700, David J. Andruczyk wrote: > > > > since there is NO other wisget that can > > be used to display rapidlychanging text. > > Most widgets can do it. Just do gdk_draw_layout() on > whatever you want. > > > (it's a textual display > > for a realtime datalogger, so fast updating is wanted) > > Updating textual information 30x a second (2007-March/msg00116) > does not make any sense though. it can be more work to make non-textual and textual elements update at a different rate than to just swallow the cost and do them both on the same interval. oh for an X toolkit that was really driven by the vertical retrace interrupt not realistic given network transparency, but a hacker can dream, can't s/he ? --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, Mar 29, 2007 at 12:43:20PM -0700, David J. Andruczyk wrote: > > since there is NO other wisget that can > be used to display rapidlychanging text. Most widgets can do it. Just do gdk_draw_layout() on whatever you want. > (it's a textual display > for a realtime datalogger, so fast updating is wanted) Updating textual information 30x a second (2007-March/msg00116) does not make any sense though. Yeti -- http://gwyddion.net/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 12:43 -0700, David J. Andruczyk wrote: > I do this already ahead of time . I ONLY update the labels when > absolutely necessary.. > > As a workaround I moved t GTKEntries which did NOT have the > performance problem, though I can't quite make them appear like a > GtkLabel in all instances, since there is NO other wisget that can > be used to display rapidlychanging text. (it's a textual display > for a realtime datalogger, so fast updating is wanted) if you were working in C++ and using gtkmm, then its actually very easy to do this with just a drawing area. you just create a derived widget with its own pango layout, and a "set text" method. then in the expose method, just tell the pango layout to draw itself within the drawing area. no resize, no width computation, etc. in C, its quite a bit more complex, but can be done. --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 16:22 -0300, Ivan Baldo wrote: > In gtk_label_size_request there is code to get the desired width and > height of the label, that could be called on the set_text and set_label > functions to see if they differ to the current allocated ones by a > threshold, and only then call gtk_widget_queue_resize_no_redraw > (expensive?) and always do a redraw (since the text is different so > something has changed). getting the height+width is not cheap with pango. checking that the text itself has not changed should be the first line of defense. also, on another note. it seems that some people think i am a GTK developer. i am not. i write applications with GTK and because they are extremely demanding and complex, i have been forced to grapple with GTK in a way that hopefully most of you are not. --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
I do this already ahead of time . I ONLY update the labels when absolutely necessary.. As a workaround I moved t GTKEntries which did NOT have the performance problem, though I can't quite make them appear like a GtkLabel in all instances, since there is NO other wisget that can be used to display rapidlychanging text. (it's a textual display for a realtime datalogger, so fast updating is wanted) I have managed in some themes to get the entry's background color to change to that of it's parent, but in some themes the colors don't match and I end up with a different colored rectangle around the text. (which I can live with for the time being as the cpu usage dropped from 45% (on a 2.1Ghz machine) down to 4% by changing from GtkLabels to GtkEntries.. --- Ivan Baldo <[EMAIL PROTECTED]> wrote: > Hello. > > El 29/03/07 12:26, Paul Davis escribió: > > this is a sort of known "bug". setting the text of a label > causes a > > recompute of the label's size, which can propagate up the > containing > > widget tree. add Pango into the mix, and that resetting is very > costly. > > the same is not true of text entries, because they never resize > based on > > their contents. > > > > evolution, sodipodi (the precursor to inkscape) and a few other > projects > > have implimented their own labels that do not do this, for > precisely the > > reason you are now discovering. > > > I don't know if this applies to the original person with the > problem, > but there is a simple optimization for when an application > repeatedly > sets the same text to the label. > In gtk_label_set_text and gtk_label_set_label a simple strcmp of > the str > argument against the label or text fields of the label structure > can > avoid all re-computations and mallocs and frees when the text > specified > is the same as the previously one. > > In my case, I write applications in a very dumb way, I expect > that GTK > detects such silly things and avoid computations when it can. > For example in a current application that I am working I set > values for > a group of spinbuttons when only one changes, so I set all the > values to > the previously set ones and only change one. > Doing it in a smarter way means I need to put more time on it, > slowing > the true advancement of the application. Luckily it seems that > gtk_spinbutton_set_value checks that the value has really changed > and > avoid expensive operations if it doesn't. > I expect the same behavior in all GTK facilities, helping the > user when > it is reasonable and easy to do. > > In gtk_label_size_request there is code to get the desired width > and > height of the label, that could be called on the set_text and > set_label > functions to see if they differ to the current allocated ones by > a > threshold, and only then call gtk_widget_queue_resize_no_redraw > (expensive?) and always do a redraw (since the text is different > so > something has changed). > > I am not an expert on GTK so I am really shy to try to implement > this, > benchmark it, test it, etc. since I don't understand it fully... > Also because of that, maybe this email is totally wrong, I may be > > misunderstanding everything :). > > Goodbye. > > -- > Ivan Baldo - [EMAIL PROTECTED] - > http://ibaldo.codigolibre.net/ > ICQ 10215364 - Phone/FAX (598) (2) 613 3223. > Caldas 1781, Malvin, Montevideo, Uruguay, South America. > We believe that we are free, but in reality we are not! Are we? > Alternatives: [EMAIL PROTECTED] - http://go.to/ibaldo > > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- David J. Andruczyk Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
Hello. El 29/03/07 12:26, Paul Davis escribió: > this is a sort of known "bug". setting the text of a label causes a > recompute of the label's size, which can propagate up the containing > widget tree. add Pango into the mix, and that resetting is very costly. > the same is not true of text entries, because they never resize based on > their contents. > > evolution, sodipodi (the precursor to inkscape) and a few other projects > have implimented their own labels that do not do this, for precisely the > reason you are now discovering. > I don't know if this applies to the original person with the problem, but there is a simple optimization for when an application repeatedly sets the same text to the label. In gtk_label_set_text and gtk_label_set_label a simple strcmp of the str argument against the label or text fields of the label structure can avoid all re-computations and mallocs and frees when the text specified is the same as the previously one. In my case, I write applications in a very dumb way, I expect that GTK detects such silly things and avoid computations when it can. For example in a current application that I am working I set values for a group of spinbuttons when only one changes, so I set all the values to the previously set ones and only change one. Doing it in a smarter way means I need to put more time on it, slowing the true advancement of the application. Luckily it seems that gtk_spinbutton_set_value checks that the value has really changed and avoid expensive operations if it doesn't. I expect the same behavior in all GTK facilities, helping the user when it is reasonable and easy to do. In gtk_label_size_request there is code to get the desired width and height of the label, that could be called on the set_text and set_label functions to see if they differ to the current allocated ones by a threshold, and only then call gtk_widget_queue_resize_no_redraw (expensive?) and always do a redraw (since the text is different so something has changed). I am not an expert on GTK so I am really shy to try to implement this, benchmark it, test it, etc. since I don't understand it fully... Also because of that, maybe this email is totally wrong, I may be misunderstanding everything :). Goodbye. -- Ivan Baldo - [EMAIL PROTECTED] - http://ibaldo.codigolibre.net/ ICQ 10215364 - Phone/FAX (598) (2) 613 3223. Caldas 1781, Malvin, Montevideo, Uruguay, South America. We believe that we are free, but in reality we are not! Are we? Alternatives: [EMAIL PROTECTED] - http://go.to/ibaldo ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 10:48 -0700, David J. Andruczyk wrote: > --- Michael Ekstrand <[EMAIL PROTECTED]> wrote: > > > On Thu, 2007-03-29 at 09:24 -0700, David J. Andruczyk wrote: > > > Though when a widget implementation causes 5-10x more cpu usage > > due > > > to a bad design. I think it warrants attention. > > > > > > [suggested fix snipped] > > > > > > It would solve the cpu usage problem from the resize triggers > > and > > > not break backwards compat. It's also something that should > > have > > > been done 3-5 years ago. > > > > It's open-source software. If this issue is that important to > > you, > > submit a patch. Criticizing the volunteers working on GTK+, who > > evidently haven't found this to be a significant enough issue to > > warrant > > this kind of attention, isn't a constructive way to promote > > change. > > > > I did my part by SUBMITTING BUG REPORTS, several in fact.. > I'm an not a GTK+ wizard, nor do I know all the intricacies about > how it renders. hence I GAVE them the information ,described the > problems, and it was tossed out. I am not a GTK developer; I'm more of a list lurker. But I do use GTK for developing and I am familiar internal GTK code. So I merely give my opinion. The reasons for this being marked as "won't fix" have been, in my opinion, fairly clearly expressed on the list. Unless you can a) argue persuasively why changing this behavior (the so-called bug) is worthwhile to the majority of GTK users, preserves the ABI, does not introduce new behaviors or side effects or b) demonstrate code that does these things, then you need to accept the opinions of the developers and move on with your own work-around code. Complaining here will not bring about any progress on this issue. I believe I can summarize the reasons why GTK developers have dismissed your bug report: - The bad behavior is only apparent in a corner use case of GtkLabel that was never an intended use. GtkLabels were never designed for constant updating. The nominal use case is a on-time setup, incurring no more cost than any other widget setup. Other uses likely need to be fulfilled by another built-in widget or custom widget. - Changing the code to fix this behavioral problem would break the binary compatibility and likely introduce new bugs and side-effects. A new API for GtkLabel should be introduced to the GTK3 work, not GTK2. Despite what you say, your changes would indeed introduce a new API and break GTK2.x compatibility (ABI). - The cost in developer time of changing this behavior is simply too high. Since it does not affect the speed and stability of 99% of GTK apps, developer time should be spent elsewhere. Another minor issue may have been the way you wrote up the bug report. Bug reports that give the impression that the GTK developers owe you something will likely not elicit a favorable response, especially given the points above. If it was similar to your posts on this issue, then I can imagine that the human factor may have played a role. In short, I think GTK developers have agreed with you that this behavior of the GtkLabel during updates can cause issues, but given the points I mentioned, will not fix this corner case for you in the stable GTK2 branches. However they have suggested some very good workarounds, including writing/borrowing your own GtkLabel widget that would work better for your use case. In fact they even told you where to go to see exactly such code. cheers, Michael > > > > -- David J. Andruczyk > > > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
--- Michael Ekstrand <[EMAIL PROTECTED]> wrote: > On Thu, 2007-03-29 at 09:24 -0700, David J. Andruczyk wrote: > > Though when a widget implementation causes 5-10x more cpu usage > due > > to a bad design. I think it warrants attention. > > > > [suggested fix snipped] > > > > It would solve the cpu usage problem from the resize triggers > and > > not break backwards compat. It's also something that should > have > > been done 3-5 years ago. > > It's open-source software. If this issue is that important to > you, > submit a patch. Criticizing the volunteers working on GTK+, who > evidently haven't found this to be a significant enough issue to > warrant > this kind of attention, isn't a constructive way to promote > change. > I did my part by SUBMITTING BUG REPORTS, several in fact.. I'm an not a GTK+ wizard, nor do I know all the intricacies about how it renders. hence I GAVE them the information ,described the problems, and it was tossed out. -- David J. Andruczyk We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 09:24 -0700, David J. Andruczyk wrote: > Though when a widget implementation causes 5-10x more cpu usage due > to a bad design. I think it warrants attention. Of course the speed of it can and should be improved across the board. But to say that it is bad design is not correct. It is no more poor design than any other widget. Except for the corner cases where GtkLabel is not appropriate (such as in your case), the setup time is only incurred once, just like any other widget. To hack in logic to deal with your corner case would likely lead to even poorer design. > > Add one simple function call to assign a label a FIXED size > (similar to the call for GtkEntries) so as to prevent the resize up > the widget tree syndrome. When a label update occurs, either > truncate anything past that limit, or if the ellipses property is > set to use that instead to show the label is larger than it's > allocated area. I don't think it is that simple. First of all, a fixed size that you think is right for your app may or may not even have enough room to display any of the text of the label on other people's systems. They may not be using the same font for the default in GTK, not the same DPI, etc. Thus how would you specify "fixed?" Further a GtkLabel can contain markup and cover multiple lines and have different kinds of alignment and justification. > > It would solve the cpu usage problem from the resize triggers and > not break backwards compat. It's also something that should have > been done 3-5 years ago. It would break binary compatibility. Your best bet is to follow the lead of evolution and other projects that need similar functionality and implement a custom widget, and perhaps submit it to the GTK head developers as an ancillary widget. Michael > gtk-list@gnome.org ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 09:24 -0700, David J. Andruczyk wrote: > Though when a widget implementation causes 5-10x more cpu usage due > to a bad design. I think it warrants attention. > > [suggested fix snipped] > > It would solve the cpu usage problem from the resize triggers and > not break backwards compat. It's also something that should have > been done 3-5 years ago. It's open-source software. If this issue is that important to you, submit a patch. Criticizing the volunteers working on GTK+, who evidently haven't found this to be a significant enough issue to warrant this kind of attention, isn't a constructive way to promote change. - Michael -- Michael Ekstrand Research Assistant, Scalable Computing Laboratory Goanna, compute cluster and InfiniBand network monitor tool: http://www.scl.ameslab.gov/Projects/Monitor/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
Though when a widget implementation causes 5-10x more cpu usage due to a bad design. I think it warrants attention. Add one simple function call to assign a label a FIXED size (similar to the call for GtkEntries) so as to prevent the resize up the widget tree syndrome. When a label update occurs, either truncate anything past that limit, or if the ellipses property is set to use that instead to show the label is larger than it's allocated area. It would solve the cpu usage problem from the resize triggers and not break backwards compat. It's also something that should have been done 3-5 years ago. --- Paul Davis <[EMAIL PROTECTED]> wrote: > On Thu, 2007-03-29 at 09:04 -0700, David J. Andruczyk wrote: > > And the GTK+ developers haven't fixed this because of what? > pride? > > > > I've seen this issue in GTK+ for YEARS, and filed bug reports > on it > > for several years only to be shot down and turned away by them. > > > That's disappointing. > > its not actually a bug, which is why i wrote "bug". its an issue > with > the semantics of what a "label" is and how it should behave. > > for many applications, the current behaviour of GtkLabel is > correct and > desired. for many others, it isn't, hence the work that > Evolution's team > had to do. > > there are very few people working on the GTK infrastructure. > adding a > whole new semantic for labels (or even an option to disable > resizing, > which has several side effects) is not likely high on the couple > of > personal TODO lists that anyone has. > > --p > > > -- David J. Andruczyk Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 09:04 -0700, David J. Andruczyk wrote: > And the GTK+ developers haven't fixed this because of what? pride? > > I've seen this issue in GTK+ for YEARS, and filed bug reports on it > for several years only to be shot down and turned away by them. > That's disappointing. its not actually a bug, which is why i wrote "bug". its an issue with the semantics of what a "label" is and how it should behave. for many applications, the current behaviour of GtkLabel is correct and desired. for many others, it isn't, hence the work that Evolution's team had to do. there are very few people working on the GTK infrastructure. adding a whole new semantic for labels (or even an option to disable resizing, which has several side effects) is not likely high on the couple of personal TODO lists that anyone has. --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
And the GTK+ developers haven't fixed this because of what? pride? I've seen this issue in GTK+ for YEARS, and filed bug reports on it for several years only to be shot down and turned away by them. That's disappointing. --- Paul Davis <[EMAIL PROTECTED]> wrote: > On Mon, 2007-03-26 at 17:17 -0700, David J. Andruczyk wrote: > > I hadn't tried that as I assumed that it was off by default > unless > > enabled.. > > > > Since a simple test program doesn't show it,. but my app does > and > > the performance hogging goes away when I comment out one line > > (gtk_label_set_text) the problem appears to be internal to GTK> > > > Another fine fellow suggested it may be due to resizing of > widgets > > caused by the label update, and showed me a way to set it to a > > fixed size, but that ahd no effect on cpu usage (still high). > > > > I managed to create a workaround by useing a GtkEntry instead, > and > > working out some trickery to make the entrie's background color > > (normally white) to match it's parent so it blends in and looks > > like a label, and presto, cpu usage went from 40-45% down to 4 > %. > > > > For some reason in my case the label updates seem to be > triggering > > some internal stuff for no good reason. when I get a little > time > > I'll try to extract that section of code int oan isolated test > > case, and if it still shows that I'll file it as a GTK+ bug. > > this is a sort of known "bug". setting the text of a label causes > a > recompute of the label's size, which can propagate up the > containing > widget tree. add Pango into the mix, and that resetting is very > costly. > the same is not true of text entries, because they never resize > based on > their contents. > > evolution, sodipodi (the precursor to inkscape) and a few other > projects > have implimented their own labels that do not do this, for > precisely the > reason you are now discovering. > > (i would have replied sooner, but was away in berlin at the linux > audio > conference with no email access or time) > > --p > > > > -- David J. Andruczyk It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Mon, 2007-03-26 at 17:17 -0700, David J. Andruczyk wrote: > I hadn't tried that as I assumed that it was off by default unless > enabled.. > > Since a simple test program doesn't show it,. but my app does and > the performance hogging goes away when I comment out one line > (gtk_label_set_text) the problem appears to be internal to GTK> > Another fine fellow suggested it may be due to resizing of widgets > caused by the label update, and showed me a way to set it to a > fixed size, but that ahd no effect on cpu usage (still high). > > I managed to create a workaround by useing a GtkEntry instead, and > working out some trickery to make the entrie's background color > (normally white) to match it's parent so it blends in and looks > like a label, and presto, cpu usage went from 40-45% down to 4 %. > > For some reason in my case the label updates seem to be triggering > some internal stuff for no good reason. when I get a little time > I'll try to extract that section of code int oan isolated test > case, and if it still shows that I'll file it as a GTK+ bug. this is a sort of known "bug". setting the text of a label causes a recompute of the label's size, which can propagate up the containing widget tree. add Pango into the mix, and that resetting is very costly. the same is not true of text entries, because they never resize based on their contents. evolution, sodipodi (the precursor to inkscape) and a few other projects have implimented their own labels that do not do this, for precisely the reason you are now discovering. (i would have replied sooner, but was away in berlin at the linux audio conference with no email access or time) --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
I hadn't tried that as I assumed that it was off by default unless enabled.. Since a simple test program doesn't show it,. but my app does and the performance hogging goes away when I comment out one line (gtk_label_set_text) the problem appears to be internal to GTK> Another fine fellow suggested it may be due to resizing of widgets caused by the label update, and showed me a way to set it to a fixed size, but that ahd no effect on cpu usage (still high). I managed to create a workaround by useing a GtkEntry instead, and working out some trickery to make the entrie's background color (normally white) to match it's parent so it blends in and looks like a label, and presto, cpu usage went from 40-45% down to 4 %. For some reason in my case the label updates seem to be triggering some internal stuff for no good reason. when I get a little time I'll try to extract that section of code int oan isolated test case, and if it still shows that I'll file it as a GTK+ bug. (Again) NOTE these problems (high cpu) exist on both linux and Win32 platforms, as my app goes both ways. --- Paul Davis <[EMAIL PROTECTED]> wrote: > On 3/25/07, David J. Andruczyk <[EMAIL PROTECTED]> wrote: > > Has anyone else noticed excessive cpu usage when updating > certain > > GTK+ (2.10.x) widgets? > > > > I have a piece of software that updates a set of text fields > > (GtkLabel's) and uses progress bars to indicate a quantity > > graphically, and am finding excessively high amounts of CPU > usage > > when these calls are made. Commenting out calls to > > "gtk_label_set_text" and "gtk_progress_bar_set_fraction" > brings > > cpu usage back to near zero levels.. I have profiled my code > > extensively using gprof/memprof and the problem is not inside > of my > > own code fro mwhat the profiler tells me. > > > > I would NOT expect updating approx 10 labels perhaps 5-10 times > per > > second (ie. when data chages) on a 1.8Ghz machine be so cpu > hungry. > > I have code in place ALREADY to prevent unnecessary updates. > > Without that bit of code, cpu usage will easily max the machine > > even at lower update rates. > > > > I can only suspect that it's an internal GTK+ or pango issue, > as my > > own custom widgets (custom automotive gauges, i.e. > > http://megatunix.sourceforge.net/cluster.gif) are far more > > graphically intensive and I can have multiple instances (about > 4-6 > > updating at any one time for this informal test) of them > updating > > at 30x per second and only have a minimal cpu load of about 15% > > > > Does the label or progress bar code use > > gtk_widget_invalidate_region? (I found that to have a major cpu > > penalty when developing my custom widgets so I stopped using it > in > > my design.) > > > > > > > > -- David J. Andruczyk > > > > > > > > > > > Now that's room service! Choose from over 150,000 hotels > > in 45,000 destinations on Yahoo! Travel to find your fit. > > http://farechase.yahoo.com/promo-generic-14795097 > > ___ > > gtk-list mailing list > > gtk-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gtk-list > > > > This might be a shot in the dark, but have you tried disabling > pango's > markup processing with this function: > http://developer.gnome.org/doc/API/2.0/gtk/GtkLabel.html#gtk-label-set-use-markup > > HTH, > Paul > -- David J. Andruczyk Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 3/25/07, David J. Andruczyk <[EMAIL PROTECTED]> wrote: > Has anyone else noticed excessive cpu usage when updating certain > GTK+ (2.10.x) widgets? > > I have a piece of software that updates a set of text fields > (GtkLabel's) and uses progress bars to indicate a quantity > graphically, and am finding excessively high amounts of CPU usage > when these calls are made. Commenting out calls to > "gtk_label_set_text" and "gtk_progress_bar_set_fraction" brings > cpu usage back to near zero levels.. I have profiled my code > extensively using gprof/memprof and the problem is not inside of my > own code fro mwhat the profiler tells me. > > I would NOT expect updating approx 10 labels perhaps 5-10 times per > second (ie. when data chages) on a 1.8Ghz machine be so cpu hungry. > I have code in place ALREADY to prevent unnecessary updates. > Without that bit of code, cpu usage will easily max the machine > even at lower update rates. > > I can only suspect that it's an internal GTK+ or pango issue, as my > own custom widgets (custom automotive gauges, i.e. > http://megatunix.sourceforge.net/cluster.gif) are far more > graphically intensive and I can have multiple instances (about 4-6 > updating at any one time for this informal test) of them updating > at 30x per second and only have a minimal cpu load of about 15% > > Does the label or progress bar code use > gtk_widget_invalidate_region? (I found that to have a major cpu > penalty when developing my custom widgets so I stopped using it in > my design.) > > > > -- David J. Andruczyk > > > > > Now that's room service! Choose from over 150,000 hotels > in 45,000 destinations on Yahoo! Travel to find your fit. > http://farechase.yahoo.com/promo-generic-14795097 > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > This might be a shot in the dark, but have you tried disabling pango's markup processing with this function: http://developer.gnome.org/doc/API/2.0/gtk/GtkLabel.html#gtk-label-set-use-markup HTH, Paul ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Mon, 2007-03-26 at 11:27 -0700, David J. Andruczyk wrote: > I changed from gtk_labels to gtk_entries instead and cpu usage > drops to near zero now. Took me a while to figure out how the hell > to get the entry's background to change so that it essentially > disappeared (and displays looking exactly like a label). > > so as of now my problem is solved by a hack around a problem INSIDE > of GTK+. > > It doesn't render quite right in WinXP however. (and I suspect it > may do that in various GTK+ themes), but my users can live with it > now, as they can at least run it without it bringing their systems > to their knees). Hmm. Maybe this performance issue is a windows-only thing. Before you post here, I had read your posts but not realized this was on Windows. > > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
I changed from gtk_labels to gtk_entries instead and cpu usage drops to near zero now. Took me a while to figure out how the hell to get the entry's background to change so that it essentially disappeared (and displays looking exactly like a label). so as of now my problem is solved by a hack around a problem INSIDE of GTK+. It doesn't render quite right in WinXP however. (and I suspect it may do that in various GTK+ themes), but my users can live with it now, as they can at least run it without it bringing their systems to their knees). --- [EMAIL PROTECTED] wrote: > On 3/26/07, David J. Andruczyk <[EMAIL PROTECTED]> wrote: > > I added your code, and it DOES stop the display from resizing > > widgets when the labels display small values, > > Yea! \o/ > > > but it DOES NOT drop > > cpu usage at all. so internally GTK+ is still going something > with > > regards to the labels. > > Oh dear :-( > > What about that tiny program that just changes labels? Is that > fast on > your machine? > > I guess I'd try experimentally commenting out other elements of > the > interface. Sorry not to have any more ideas. > > John > -- David J. Andruczyk Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 3/26/07, David J. Andruczyk <[EMAIL PROTECTED]> wrote: > I added your code, and it DOES stop the display from resizing > widgets when the labels display small values, Yea! \o/ > but it DOES NOT drop > cpu usage at all. so internally GTK+ is still going something with > regards to the labels. Oh dear :-( What about that tiny program that just changes labels? Is that fast on your machine? I guess I'd try experimentally commenting out other elements of the interface. Sorry not to have any more ideas. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
I added your code, and it DOES stop the display from resizing
widgets when the labels display small values, but it DOES NOT drop
cpu usage at all. so internally GTK+ is still going something with
regards to the labels.
If I comment out gtk_label_set_text() in my code cpu usage drops
from 45% to 4%. (dual cpu AMD 2.1Ghz, 3GB ram)
--- [EMAIL PROTECTED] wrote:
> On 3/26/07, David J. Andruczyk <[EMAIL PROTECTED]> wrote:
> > I think the resizing is the culprit. I was tempted to use
> > gtk_entries instead as you can assign them fixed size in
> > charactors, which is easier to handle differences in font size.
>
> You can do that with a label too. Measure the size of the string
> "8",
> then call gtk_widget_set_size_request() to lock the label to 10
> (for
> example) 8s across by 1 8 down.
>
> I do this with:
>
>
> /* Calculate the bounding box for a string rendered with a
> widget's default
> * font. Set geo to a rect with 0,0 positioned on the left-hand
> baseline.
> */
> void
> get_geo( GtkWidget *widget, const char *text, Rect *geo )
> {
> PangoLayout *layout;
> int width, height;
>
> layout = gtk_widget_create_pango_layout( widget, text );
> pango_layout_get_pixel_size( layout, &width, &height );
> g_object_unref( layout );
>
> /* FIXME ... we left/top to 0 for now.
> */
> geo->width = width;
> geo->height = height;
> geo->left = 0;
> geo->top = 0;
> }
>
> /* Set a widget to a fixed size ... width in characters.
> */
> void
> set_fixed( GtkWidget *widget, int nchars )
> {
> Rect geo;
>
> get_geo( widget, "8", &geo );
> gtk_widget_set_size_request( widget, geo.width * nchars,
> geo.height );
> }
>
>
> John
>
-- David J. Andruczyk
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
Hi David,
On 3/26/07, David J. Andruczyk <[EMAIL PROTECTED]> wrote:
> I would NOT expect updating approx 10 labels perhaps 5-10 times per
> second (ie. when data chages) on a 1.8Ghz machine be so cpu hungry.
I made a tiny test program. This updates 50 labels at 100Hz with less
than 1% CPU on my machine.
--
/* compile with
* gcc -Wall try16.c `pkg-config gtk+-2.0 --cflags --libs`
*/
#include
#include
const int NUM_LABELS = 50;
const int FPS = 100;
gboolean
update_labels (GtkWidget * label[])
{
int i;
for (i = 0; i < NUM_LABELS; i++)
{
char buf[256];
snprintf (buf, 256, "%d", rand ());
gtk_label_set_text (GTK_LABEL (label[i]), buf);
}
return TRUE;
}
int
main (int argc, char **argv)
{
GtkWidget *label[NUM_LABELS];
GtkWidget *win, *box;
int i;
gtk_init (&argc, &argv);
win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (win, "destroy", G_CALLBACK (gtk_main_quit), NULL);
box = gtk_vbox_new (FALSE, 0);
gtk_container_add (GTK_CONTAINER (win), box);
for (i = 0; i < NUM_LABELS; i++)
{
label[i] = gtk_label_new (NULL);
gtk_box_pack_start (GTK_BOX (box), label[i], TRUE, TRUE, 0);
}
g_timeout_add (1000 / FPS, (GSourceFunc) update_labels, label);
gtk_widget_show_all (win);
gtk_main ();
return 0;
}
-
I have Dapper still on my machine (gtk 2.8, amd64 2.7 GHz) which might
make some difference I guess. Though I think Pango has actually sped
up in 2.10.
I wonder if another reason might be resizing? Setting a label's text
can cause the label to change size, which might be forcing some
(large?) chunk of your interface to resize too. You could try using
gtk_widget_set_size_request() on your labels to make them a fixed
size.
John
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
