Re: Gtk_Tree_View, drawing speed
Hello Arne, Is it really necessary to refresh updates 400 times per second? To be honest, me as a human will not notice all these changes. What do you think about doing updates once or two times per second? (like all task managers do) E.g. you can collect all values that come from the hardware and display the average value only. Kind regards, Vlad 2012/9/26 Arne Pagel a...@pagelnet.de: Thank you for this hint, I tried it and indeed I notice a speedup, but just factor ~1,3. There must be something more. I removed all columns expect the Value column, and now I notice a speedup factor of ~3, if I remove just one column, is see a speedup factor of ~2. Now I am sure that there is some processing on cells where the corresponding data in the treestore are not touched. If I remove columns on the first treeview which is using the same tree-store I see no effect. What is interesting that I now notice also a speedup of my single elements objects, there now I can achieve an update rate of 570 requests per second. - - I just noticed that I can't compare the single element objects and structured objects in that way I did before, but anyway, with the column removing I see some potential for speeding up everything. Of course the given value of 570 requests per second is not the design goal of the program. But later I want to have many structured objects in the treeview with an acceptable update rate and not 100% CPU load. regards Arne Am 26.09.2012 10:51, schrieb jcup...@gmail.com: On 26 September 2012 07:09, Arne Pagela...@pagelnet.de wrote: Do you see any other option? Have you tried setting the fixed-height hint on the treeview? By default treeview supports variable-height rows. This is great, of course, but there is a performance penalty: whenever the model changes, the view has to rescan the model and recalculate all the heights. If all your rows are the same height, and they might be from looking at your screenshot, you can set the fixed-height hint and get treeview to just sample a single row. http://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-view-set-fixed-height-mode John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk_Tree_View, drawing speed
Hello Vlad, an update frequency about 400Hz is absolutely not necessary, and I agree that no human could follow that. My Target is 100ms. This gives an acceptable picture, even if I use later progress bars for visualization. You will defenitliy notice a difference between 100ms and 33ms. If I use numerical values, and even if you can not read the last number, you have some Information, you see that there is a fast change. The other thing is that I have build in the possibilitiy for a Binary Display where I currently use a Toggle Button. In the Future my plan is to change to a LED like view, where you also can notice very short events. Anyway, to achieve 100ms, the maximum possible update Frequency should by higher. At the moment I have just on Object with 12 Elements in my TreeView, but later I want to have more Objects with more Elements in the view, with the current approach I would already touch the boarder. Also I want to reduce the CPU load for this process. Well, an WebVideo with 30 fps and an much more changing pixels requires less CPU load. A feature I plan is also to give the possibility to log Data to a file, but if the visualization causes high CPU load, and therewith high jitter, the quility of this log will be bad One other thing is, I already know that a fast Display is possible, like if I just use 1 Element Objects. Optically there is not so much difference, so what is causing the delay. Did you ever see the Mega-Tunix Project? http://sourceforge.net/projects/megatunix/ They mad some very cool gauges which I used a few years ago, with also more then 10Hz, and acceptable CPU Load, even on a weak Industrial PC regards Arne Am 27.09.2012 13:27, schrieb Vlad Volodin: Hello Arne, Is it really necessary to refresh updates 400 times per second? To be honest, me as a human will not notice all these changes. What do you think about doing updates once or two times per second? (like all task managers do) E.g. you can collect all values that come from the hardware and display the average value only. Kind regards, Vlad ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
Em Thu, 2012-09-27 às 12:42 +0700, Ivan Shmakov escreveu: [This issue is currently being discussed in debian-devel@ [0], and it was suggested to bring it to gtk-devel-list@ as well.] What's the TL;DR? It's a very long mail, weirdly formatted, and I don't understand what you expect GLib to do vs. what it does now. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
On Thu, 2012-09-27 at 13:34 +0200, Bastien Nocera wrote:
What's the TL;DR?
I don't understand what you expect GLib to do vs. what it does now.
First two sections of the email explain it:
Abstract
It's suggested that g_get_home_dir () be changed to follow the
usual Unix convention of using ${HOME} as the user's home
directory
Status quo
The g_get_home_dir () description reads [1]:
Gets the current user's home directory as defined in the password
database.
Note that in contrast to traditional UNIX tools, this function
prefers passwd entries over the HOME environment variable.
andre
--
mailto:ak...@gmx.net
http://blogs.gnome.org/aklapper
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
On Thu, 2012-09-27 at 12:42 +0700, Ivan Shmakov wrote: Gets the current user's home directory as defined in the password database. Note that in contrast to traditional UNIX tools, this function prefers passwd entries over the HOME environment variable. The question to answer is simple: why does GLib do what it does now? git annotate says the comment dates from: commit 5a866843df0d8dc5e5b81fcf2a8a572b6db31521 Author: Matthias Clasen mcla...@redhat.com Date: Wed Feb 2 06:07:14 2005 + Move doc comments inline. Which is just moving around the original comment, so let's dig into that: $ git annotate 5a866843df0d8dc5e5b81fcf2a8a572b6db31521^ -- docs/reference/glib/tmpl/misc_utils.sgml Gives us: commit ea01de53feb47d592ba6401051ac85375e9a45a9 Author: Matthias Clasen matthi...@src.gnome.org Date: Thu Sep 9 14:06:20 2004 + Clarify the relation of g_get_home_dir() and $HOME. So...yeah, not very enlightening =/ This kind of thing is a prime example of why I am constantly asking people to rewrite commit messages to say *WHY*, not what. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
Colin Walters walt...@verbum.org writes: On Thu, 2012-09-27 at 12:42 +0700, Ivan Shmakov wrote: Gets the current user's home directory as defined in the password database. Note that in contrast to traditional UNIX tools, this function prefers passwd entries over the HOME environment variable. The question to answer is simple: why does GLib do what it does now? […] So... yeah, not very enlightening =/ This kind of thing is a prime example of why I am constantly asking people to rewrite commit messages to say *WHY*, not what. Simon McVittie was courteous to traverse the Git history for us back to the Bug 2311 [6] at the GNOME Bugzilla. (See [7].) […] There's a further clarification at [6] that the use of su(8) and sudo(8) may leave HOME pointing to a directory inaccessible by the current user. […] [6] https://bugzilla.gnome.org/show_bug.cgi?id=2311 [7] http://permalink.gmane.org/gmane.linux.debian.devel.general/176977 -- FSF associate member #7257 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
On Thu, Sep 27, 2012 at 9:35 AM, Colin Walters walt...@verbum.org wrote: On Thu, 2012-09-27 at 12:42 +0700, Ivan Shmakov wrote: Gets the current user's home directory as defined in the password database. Note that in contrast to traditional UNIX tools, this function prefers passwd entries over the HOME environment variable. The question to answer is simple: why does GLib do what it does now? git annotate says the comment dates from: commit 5a866843df0d8dc5e5b81fcf2a8a572b6db31521 Author: Matthias Clasen mcla...@redhat.com Date: Wed Feb 2 06:07:14 2005 + Move doc comments inline. Which is just moving around the original comment, so let's dig into that: $ git annotate 5a866843df0d8dc5e5b81fcf2a8a572b6db31521^ -- docs/reference/glib/tmpl/misc_utils.sgml Gives us: commit ea01de53feb47d592ba6401051ac85375e9a45a9 Author: Matthias Clasen matthi...@src.gnome.org Date: Thu Sep 9 14:06:20 2004 + Clarify the relation of g_get_home_dir() and $HOME. So...yeah, not very enlightening =/ This kind of thing is a prime example of why I am constantly asking people to rewrite commit messages to say *WHY*, not what. That commit was adding documentation. What else would you say there ? The actual commit is Tue Mar 5 00:38:54 2002 Owen Taylor otay...@redhat.com * glib/gutils.c (g_get_any_init): Where we have getpwuid[_r], use that in preference to $HOME, and only check $HOME as a fallback if getpwuid fails. (#2311) And the detailed analysis leading to this change is in http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00066.html I don't think anything has changed there, really. And it is far too late to change the behaviour of this function, a decade later. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
On 09/27/2012 04:48 PM, Ivan Shmakov wrote: $ HOME=/net/home/jrh emacs Moreover, GNU Bash started under such a Emacs instance will also use /net/home/jrh/.bashrc (instead of /home/jrh/.bashrc), and so will GNU Wget, or Lynx, and a sheer variety of other tools. … But not the bulk of GNOME, which will insist on using /home/jrh/.whatever, perhaps leaving the user no way to choose otherwise (sans of persuading the local passwd(5) — or the site's LDAP — administrator to change his or her account.) Nah, you can use XDG Base directories to get the bulk of GNOME to use another directory for files, config, settings and so on. [1] Set $XDG_CONFIG_HOME, $XDG_DATA_HOME and $XDG_CACHE_HOME. These are exposed to GLib based software as g_get_user_data_dir(), g_get_user_cache_dir() and g_get_user_config_dir(). GNOME is actively moving towards using those. [2] FWIW, the default values for those are supposed to be derived from $HOME according to the XDG Basedir spec. So if the spec is to be taken literally it seems like we should be using $HOME instead of g_get_home_dir(). But anyway, there is a way to use environment variables to change where the 'bulk of GNOME' looks for its stuff. And where not, there is active progress in fixing this issue. Cheers, Stef [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html [2] https://live.gnome.org/GnomeGoals/XDGConfigFolders ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_widget_set_size_request stopped working with GTK3
Hi, with GTK2 some applications used to set the minimum size of some widgets using gtk_widget_set_size_request. E.g. the min size of a GtkImage. This no longer works with GTK3 and the min size of the GtkImage is that of the underlying image, e.g. a GdkPixbuf. There is also a bug report here: https://bugzilla.gnome.org/show_bug.cgi?id=670068 Is gtk_widget_set_size_request broken? Or how is an application supposed to set (or override if the app knows better) the min size? Steffen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
On 09/28/2012 02:16 AM, Steffen Gutmann wrote: Hi, with GTK2 some applications used to set the minimum size of some widgets using gtk_widget_set_size_request. E.g. the min size of a GtkImage. This no longer works with GTK3 and the min size of the GtkImage is that of the underlying image, e.g. a GdkPixbuf. There is also a bug report here: https://bugzilla.gnome.org/show_bug.cgi?id=670068 Is gtk_widget_set_size_request broken? Or how is an application supposed to set (or override if the app knows better) the min size? gtk_widget_set_size_request() I must admit the docs are incorrect about this, it says: Sets the minimum size of a widget; that is, the widget's size request will be/|width|/by/|height|/. You can use this function to force a widget to be either larger or smaller than it normally would be. But what it should say: Sets the minimum size of a widget; that is, the widget's size request will be/|width|/by/|height|/. You can use this function to force a widget to be larger than it normally would be. In other words, as Cosimo already mentioned in the report, a widget can never be smaller than the minimum size reported by the implementation. He also mentioned that you can configure that particular widget to actually be smaller. Two other options are: o If you cant display the whole widget, put it in a scrolled window o Use clutter-gtk library to put the GtkWidget one a stage and then scale it and transform it to the desired size ;-) Cheers, -Tristan disclaimerThis email may reach you with EVIL HTML formatting which of course has no place in emails... for some config reasons TB needed to be used instead of Evo... and I still have to find the switch to NUKE EVIL HTML from emails/disclaimer Steffen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
