Created attachment 8209 Image showing the load problem when mouse is inside button Holding the mouse over the panel button, while the calendar is open (button clicked once), will result in 100% cpu spin. If the mouse leaves the panel-button, then the problem goes away. It seems to be a problem with the (toggle-) button in the panel. This problem has been persistent across several revisions. Running Xfce spins of fedora 27, 28 and 29 (fully updated to current) all have the same behaviour. An image is attached to show the problem. Please note where the mouse-pointer is located for the two cases. The image was generated on clean FC29 install with plugin version: xfce4-datetime-plugin-0.7.0-20.fc29.
I have seen similar problems caused by a theme, can you try another one?
Yes, indeed, there seems to be a relation to the theme style. Switching the style in Settings/Appearance/Style to different ones does make a difference (BTW, window manager style set to Nodoka). I have Clearlooks as default, which exhibits the problem. However, cycling through the list indicates that many theme styles suffer from the same problem and others do not. Just a sample of styles tested: - Arc* no problem - Bluebird no problem - Murrina* 100% load - Clearlooks 100% load - ClearlooksClassic 100% load - Clearlooks-Phenix no problem - Crux, Glider, Glossy 100% load - Xfce* no problem So, it seems there is a common theme-based problem.
This is the bug about the similar problem: https://bugzilla.xfce.org/show_bug.cgi?id=14771 I cannot reproduce this cpu load with Crux nor Clearlooks. datetime-0.7.0 is already gtk3-based, maybe those themes are gtk2 so it falls back to Adwaita. Can you this theme?
Both Adwaita and Adwaita-dark exhibit the 100% load issue. You are suggesting that this is a compatibility issue between gtk2 and gtk3. There is data for the Adwaita themes for gtk2 on the disk. There also is a gtk3 reference (/usr/share/themes/Adwaita/gtk-3.0/gtk.css), which says "Adwaita is now part of GTK+ 3...". This may mean that there is a loading priority issue in gtk3?
I have no idea, it could be due the several css tricks datetime uses since it was ported to gtk3: https://git.xfce.org/panel-plugins/xfce4-datetime-plugin/tree/panel-plugin/datetime.c?id=e2db00d5eb9c6de12a3c9f82e572f7b2ea1bee8e#n346 Out of curiosity, is there any reason to use datetime instead of clock plugin?
I guess there are some compatibility issues deep down. It might be that there is a "on hover" hook in the background, which is handled differently. But this is far from my expertise. On Clock vs DateTime: Well, I use the datatime plugin mostly out of habit and attempting to prevent myself from learning a changed environment. That said, the clock plugin has a more difficult configuration dialog, where you are forced to read documentation for the strftime format and the pango styling (I use <span font="9">%a. %d %b %Y%n%H:%m:%S</span>). Especially the pango doc is confusing because it is /almost/ like html styling, but not quite. I can match the button's visual appearance almost, but not 100% (appears to be due to slight font differences). If the datetime plugin should be marked as obsolete (replaced by the clock plugin), then the functionality in the configuration should be ported in a more natural way. In terms of interaction design: the affordances in the configuration dialog, as generated with the datetime plugin, are currently not ported nor usable with the clock plugin. Therefore, the user will try to find an alternative before accepting to learn new tricks. Alleviating this problem may be as easy as extending the custom formats drop-down list to include all formats of the datetime plugin (i.e. include the date in the format). A secondary help in the interaction design would be to show the strftime format when selecting a predefined customized format. This will direct the user to a line of thought. Finally, when a "Custom" format is typed, it should not be deleted when the format drop-down list is cycled (currently, it will always revert to previously selected predefined format from the list). Removing user input, especially after the user has been working (hard) on it, feels like defeat.
(In reply to Andre Miranda from comment #5) > Out of curiosity, is there any reason to use datetime instead of clock > plugin? I just discovered that the Clock plugin does not get the time from the system all the time (should call gettimeofday() on a regular basis). When I (re)started ntpd on my system to correct the system clock, the clock plugin just showed the _old_ time. Now I am a bit curious because I cannot find a process for the clock plugin and therefore not easily see where the source is.
(In reply to Bertho from comment #7) > I just discovered that the Clock plugin does not get the time from the > system all the time (should call gettimeofday() on a regular basis). When I > (re)started ntpd on my system to correct the system clock, the clock plugin > just showed the _old_ time. > > Now I am a bit curious because I cannot find a process for the clock plugin > and therefore not easily see where the source is. Never mind... I'm just a stupid old fool... Found the source as part of the panel code. And it does read the system time. My format had %m and not %M in the minute part. Well, months and minutes do not progress at the same speed (unless you are {comp,st}ressed enough to perceive time as a special spatial variable).
Odd, I still cannot reproduce this bug with Adwaita or Adwaita dark. A random guess: I found out last week that gtk3-based plugins that are button-based will emit a "style-set" signal whenever the cursor moves over it. In your case possibly this signal is emitted continuously even with the cursor not moving. If you're able to troubleshoot this, you can enable GtkInspector activation via keystrokes[1], then open datetime properties dialog and press ctrl+shift+d. You may now find a GtkToggleButton instance in the object tree, double click it. Then go to the Signals section, press the record button and watch for "style-set" event count. Please let me know if it increases insanely even if you don't move the cursor over the plugin. With regards to datetime vs clock, thanks for you commentaries, we are not deprecating datetime-plugin, at least not now, but it's worth to know from users what we have to improve in clock before killing datetime. 1 - gsettings set org.gtk.Settings.Debug enable-inspector-keybinding true
Yes, the 'style-set' signal fires at roughly 47 times per second and followed in count by the 'style-updated' signal. That does seem to be quite excessive, However, when I checked the CPUs which processes/threads were eating the cycles, then it became obvious that there is an interaction with the X-server. The Xorg process is at 99% when the mouse is in the button area (the applet is at 10..20%). My new machine (dell latitude 5590) runs with an Intel adapter (Intel(R) UHD Graphics 620 (Kabylake GT2)). The same problem was seen on older dell (latitude 5540), which also runs with the default Intel chipset. A third laptop (old asus) also runs on the internal Intel graphics card and exhibits the problem. That makes this a pattern using the Xorg driver for the Intel graphics, all running the i965 DRI driver. All three machines have an internal Intel GPU. The two older machines also have nvidia GPUs, but they appear to be dormant. The newest machine has only one GPU. How do you debug the X interaction? Maybe a command fails and is just ping-ponging between gdk and the x-server?
Good news, now I can finally reproduce the issue! Bad news, I still have no idea what may be cause :) Here the wrapper process is about 5% of CPU and I see loads of style-set/updated signals being fired, the calendar just has to be open, the cursor doesn't have to be over the button. I don't think the video driver has any implication here, I may be wrong, but it's highly unlikely. What I discovered so far: - Removing the css code to set font styles makes no difference. - When the cursor "enters" the button about 30 signals are generated and on signal is created when the cursor "leaves. For greybird it generated only one signal per enter/leave. - Removing gtk_toggle_button_set_active from pop_calendar_window prevents the continuous generation of style-set/updated. That last remark leads me to think it is likely a problem in panel itself, however other plugins with toggle button such as clock and cpufreq do not display the same misbehavior when their button is toggled.
(In reply to Andre Miranda from comment #11) > I don't think the video driver has any implication here, I may be wrong, but > it's highly unlikely. I can follow your thoughts. I did check the X-events for the button (window) and they are not causing the problem (only few X-events occur periodically). I'm crossing my fingers that you can find the problem. I'm way out of my comfort zone in these applications.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/panel-plugins/xfce4-datetime-plugin/-/issues/26. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev