Re: Install GTK on windows using no official installers
Beware that doing so (incorporating a "private" GTK+ release intro your installer) will mostly likely BREAK or screw up ANY OTHER GTK+ apps on the box.. I have this problem with my software (MegaTunix). I recommend my users to use the gladewin32.sf.net GTK+ runtime as it has GTK+, glade, and gtkglext, all in a simple 5 click installer. Users report that if they had gaim installed, this breaks things horribly. They can't run my SW with gaim's GTK+ as it is missing gtkglext, and cairo dll.s, and instlaling the sladewin32.sf.net runtime doesn't resolve it as gaim's "privatized" gtk+ screws up the rest of the system except for itself. So adding in your own privatized version is likely to affect other applications. The best "all in one" runtime I have found for me is the gladewin32.sf.net as it keeps it's DLL's OUT of the window's dir (everything goes into C:\GTK) It also includes bits that other GTK+ libs DO NOT have, like gtkglext (openGL extension), glade/libglade, libxml2, cairo, etc. --- Tor Lillqvist <[EMAIL PROTECTED]> wrote: > Bleriot Trece writes: > > is it possible to copy a set of GTK files (DLLs > or whatever) and, > > in this way, make GTK available WITHOUT using an > official GTK > > installer? > > Of course. And anyway, the degree of officialness of > the various GTK > installers out there isn't that clear. > > > what files should be copied, what environment > variables > > modified... and so on? > > I could try to list them, but you learn best by > doing, so I will tell you > how to do that: > > Start by fetching from > http://ftp.gnome.org/pub/gnome/binaries/win32/ > the latest run-time zipfiles (not the *-dev-* ones) > for gtk+, pango, > atk, glib. From the depencensies subfolder get the > latest cairo, > gettext, and libiconv run-time zipfiles. If you know > that your app > will need the libpng pixbuf loader at run-time, also > get libpng and > zlib. > > Unzip all the above in some new empty folder. Add > the "bin" folder of > that to your PATH environment variable. > > Then start removing stuff you think your app and > your customers won't > need. For instance, if you don't have any need for > localised strings from > gtk+ etc, you can remove everything from lib/locale > . If you want localised > strings, but not for some "exotic" languages, remove > the corresponding > subfolders from lib/locale. > > If you don't need pixbuf loaders for "exotic" image > formats, remove > those dlls from lib/gtk-2.0/2.10.0/loaders . > > If you don't need gtk+ input modules, drop > lib/gtk-2.0/2.10.0/immodules > . Also, then edit etc/gtk-2.0/gtk.immodules. > > If you want the MS-Windows theme to be the default, > create a file > etc/gtk-2.0/gtkrc with the line gtk-theme-name = > "MS-Windows" . Otherwise, > if you don't want the end-users to be able to change > theme engine, drop > lib/gtk-2.0/2.10.0/engines and > share/themes/MS-Windows . > > If you don't need the Freetype2 Pango backend (and > you presumably > won't), remove bin/linpangoft2-1.0-0.dll. > > Hmm, that should be about it. If I forgot something > obvious that can > also be dropped, please follow-up... > > Then you add what's left to your application's > installer. > > Don't change the folder substructure. Keep the DLLs > in the "bin" > subfolder for instance. > > It's easiest to put your application's exe file in > the same "bin" folder > and have your Start Menu etc shortcuts point to > that. Otherwise you will > have to make sure that the "bin" folder is included > in PATH when the > end-user runs your app, either by having your > installer modifying the > environment variable, using the App Paths Registry > method, using a tiny > wrapper executable that modifies PATH, or something > else. > > The recommended way (at least if I am doing the > recommentation) is indeed > to install a copy of GTK+ with each application (or > set of applications > originating from the same maintainer / packager) > that uses it. This is > unlike Linux, I know. But attempts to use a shared > GTK+ installation on > Windows between applications developed and > distributed by unrelated parties > have not really been successful. > > --tml > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- David J. Andruczyk __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
I have found glade to be (mostly) a blessing and (occasionally) a curse. My app is 100% in glade, (and it's moderately sized, about 25,000 lines), and having the gui elements be loadable on demand is a key point to my app (as it adapts during runtime). It allows me to rapdily alter the gui to improve usability, layout, etc. and ALSO lowers the barrier to entry for outsiders (i.e. non programmers) to alter the gui in ways I did not envision. It has downfalls, but if I had to take the choice of hardcoding my entire gui in code (which I had done at one time and it became unmanageable and bloated), or using glade, and working around it's deficiencies, I would take the glade route every time. --- David Neèas (Yeti) <[EMAIL PROTECTED]> wrote: > On Tue, Apr 17, 2007 at 10:42:08AM -0400, Tristan > Van Berkom wrote: > > > > If your program is a long term investment and > undergoes frequent > > refactoring, then do it now :) you will > significantly improve your > > code's legibility, reduce lots of code and as > such; add value > > to your product, this is not just my pointed > opinion - libglade > > reduces complexity from your code > > It redistributes complexity to other places and to > relations > between the code and the other places, if that is > what you > mean by `reducing complexity from your code', > however it > does not reduce the total. The typical recommended > use > scatters strongly coupled information to distant > places, > destroys modularity and discourages refactoring into > functional (reusable) units such as custom widgets > and other > classes. If the interface changes dynamically and/or > it > reflects some data structures (unknown at compile > time), > adding libglade into that is just a recipe for > headache. > > > the fact that you can later dynamically change > > your UI using a designer tool without editing your > source code is > > only added sugar. > > Whether this is a featue or bug is yet to be > determined. > > > Consider that adding a user visible feature to > your > > program will become a matter of: > >a.) Adding a control widget to your GUI with a > designer tool and then > >b.) Adding a callback function that will > interface with your core > >application code to perform a task, maybe > also > >c.) Fetching a widget pointer from the libglade > built hierarchy to > >provide the user with feedback from the > core. > > The code representing the dynamics of the user > interface > forms the bulk of the code, accounts for almost all > the > complexity and often shares bits with construction > code. > If simplifying construction -- the easy and > straightforward > part -- radically simplifies your program, your > program is > most likely Hello world. > > c) in its typical use is global variables in > disguise (a > flat pool with everything). > > Yeti > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- David J. Andruczyk __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
button);
> strcpy(toolTip, "Display NEXT Screen of Trace
> Files");
> gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button,
> toolTip, toolTip);
>
> hbox = gtk_hbox_new(FALSE, 0);
> label = gtk_label_new("min:");
> MTfixed[MIN] = entry = gtk_entry_new();
> g_signal_connect(MTfixed[MIN], "activate",
> G_CALLBACK(reMag), &OV
> [MAGNIFYSCR]);
> gtk_entry_set_width_chars(GTK_ENTRY (entry, 5);
> gtk_container_add(GTK_CONTAINER (hbox), label);
> gtk_container_add(GTK_CONTAINER (hbox), entry);
> gtk_container_add(GTK_CONTAINER (vbox), hbox);
> strcpy(toolTip, "MIN: define as absolute (e.g.,
> 1000) or as
> Percentage of MAX/MIN Mean (e.g., 50%) (BLANK = Real
> MIN)");
> gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), entry,
> toolTip, toolTip);
>
> As another poster pointed out, this repetitive type
> of widget
> creation can be contained within its own routine.
> But basically,
> once you've got the various types of widgets and
> layouts you require,
> it is trivial to copy and paste the code over and
> over, only
> requiring the widget's creation details to be
> changed for each new
> instance.
>
> The above snippet requires only that the entry area
> be uniquely named
> for later reference. In my code, all widgets are
> globally defined as
> GtkWidget *, casting when- and wherever appropriate.
> (Some purists
> might balk at global variables but I have no problem
> with globals
> which never change value over the entire life of a
> program,
> especially when they're widgets needed possibly
> anywhere.) To handle
> the problem of having to name so many widgets
> nonetheless, adopt a
> simple and shorthand naming convention you can
> immediately recognize,
> deduce, and even guess which makes sense somehow to
> the program and
> their usage. As well, arrays of widgets can be very
> helpful here.
>
> And like another poster, I highly recommend
> attaching as few
> callbacks as possible to the widgets. Like he does,
> as can be seen
> above, each button is attached to the same callback
> with an enum
> value passed to the callback routine. Once called,
> case statements
> handle each button's differing requirements.
> (Unlike how he does it,
> however, I do this more directly in the signal
> connection itself;
> either method works though depending on exact
> requirements, using
> g_object_*_data() may be more appropriate.) In
> general, try to
> attach like widgets to the same callback. In
> practice this won't be
> universal, some callbacks demand their own routine;
> the point is,
> maintaining code in the future is always made easier
> when the number
> of callbacks is minimized to the greatest extent
> possible.
>
> And good luck,
>
> richard>
___
> gtk-list mailing list
> [EMAIL PROTECTED]
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
-- David J. Andruczyk
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
In the case of my app (MegaTunix) the app gui is 100% glade, though some widget are built manually and placed into of a glade designed object as like others have said, they are dynamic and not predictable until during runtime. Due to the niche nature of my app, and the multitude of controls (well over 1500), I had to extend things as glade didn't do enough, but it worked and is fairly extensible even if it's design has numerous flaws... http://megatunix.sourceforge.net -- David J. Andruczyk __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
> On Fri, 13 Apr 2007 23:57:12 -0300 you wrote: > > I am curious about it and really want to know: How > do you develop your GTK > > codes? > I do a combination of by hand and via glade. Glade has several faults, the one being not being able to bind arbritrary information to widgets in the designer, which I doun't think would be possible anyways, though QT's designer offers something along those lines, as subclassing existing widgets is about 1000x easier than doing it in GTK+. So for my niche use, in order to be able to reuse signal handlers, and not end up with one handler per control, I have glue code in place that on initialization of the application it binds additional data per applicable widget which the signal handlers use to take appropriate action. so my code makes very extensive use of g_object_set_data(), and g_object_get_data(). Thus for all my buttons I have one handler std_button_handler(), and in my code I assign an enum to each control (i.e. g_object_set_data(G_OBJECT(widget), "handler" GINT_TO_POINTER(SOME_ENUM_NAME)); so that when that handler is called, it's is handled in a case statement inside that handler. -- David J. Andruczyk __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list [EMAIL PROTECTED] 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
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
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. Ha
Re: changing sensitivity of a button
You might try "g_signal_handlers_block/unblock_by_func" to block any further signal emission for that button until your conditions are met and then unblock it.. g_signal_handlers_block_by_func(G_OBJECT(YOUR_BUTTON),G_CALLBACK(your_clicked_function),data); This is an adaptation of a FAQ entry http://gtk.org/faq/#AEN843 --- Joachim Klähn <[EMAIL PROTECTED]> wrote: > Hi, > > I'm using a button to start an action on a mechanical component. > This action needs several seconds to finish. > During this time I'm switching off sensitivity of the button by > use of > gtk_widget_set_sensitive(widget,0) to prevent the user from > clicking it. > After completion of the action the button is made sensitive by > use of > gtk_button_set_sensitive(widget,1) > If the user holds position of mouse pointer and tries to repeat > the action > by pressing the button, he doesn't succed. > Futher activation of the button is only possible after the mouse > cursor > has left the button's area an then reentered. > > Has anybody an workaround. > > achim > > > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- 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
--- 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
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
--- 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
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
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
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
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
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
(severe) performance issues
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
