I have quite strange and high (high for such application) cpu usage:
88288 lucky 1 97 0 47540K 11460K select 4:32 3.42% xfce4-battery-plugi
27290 lucky 1 96 0 27364K 19420K select 2:30 0.05% sim
15187 lucky 4 20 0 12368K 8536K kserel 19:36 0.00% xmms
78261 lucky 1 96 0 12404K 7804K select 1:11 0.00% xfce4-wavelan-plugi
18050 lucky 1 96 0 51504K 16328K select 0:35 0.00% xfce4-panel
sim and xmms both are using much less cpu than battery-plugin! is it ok? )
also is it normal that plugin use so much memory?
I have a Compaq Evo n610c laptop.
> uname -a
FreeBSD ontario 6.2-STABLE FreeBSD 6.2-STABLE #12: Fri Feb 23 18:35:47 NOVT 2007 root@ontario:/usr/src/sys/i386/compile/ontario i386
Copyright (c) 1992-2007 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 6.2-STABLE #12: Fri Feb 23 18:35:47 NOVT 2007
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (1196.12-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf27 Stepping = 7
real memory = 536674304 (511 MB)
avail memory = 519979008 (495 MB)
kbd1 at kbdmux0
ACPI: overriding DSDT/SSDT with custom table
ACPI-0377: *** Info: Table [DSDT] replaced by host OS
there are following changes was made in ACPI table: added two buttons (power and sleep), LID Switch fixed.
> pkg_info | grep xfce4-bat
xfce4-battery-plugin-0.5.0_1 Battery monitor panel plugin for XFce4
under Xfce 4 Desktop Environment version 4.4.0 (Xfce 4.4)
*** Bug 2949 has been marked as a duplicate of this bug. ***
*** Bug 2950 has been marked as a duplicate of this bug. ***
I've the same "problem" (FBSD 6.2, IBM T42p). Maybe the updating frequency is too high?
I've thought the same... but it doesn't seem to be the truth...
I've recompiled the source with other values for updating frequency... a result was the same for me..
Does the memory consumption seem to grow over time, or it starts like that?
just starts like that
I'm seeing the same problem.. the cpu usage is the more worrisome issue to me. Top is showing between 3 and 8% of cpu usage by xfce4-battery-plugin on a p3 1.2ghz machine.
If it's not polling too frequently, perhaps it's something on the gtk+ side? Although I don't even have a visible label now, just the bar, so I can't imagine why that would cause it.
Confirmed on Linux (Ubuntu)
Although cant change OS field to All
made some improvment and fixes there. so, now it takes less the 1% of CPU:
1116 lucky 1 97 0 34276K 20108K select 0:07 0.29% xfce4-battery-plugi
what was fixed and added:
- improve and optimize logic and calculations during polling
- remove unneeded callings to graphics each time
- fixed FreeBSD APM code
- status more sensitive now.. based on APM_BATT_STATE and ACPI_BATT_STATE (except that this works under *BSD only...)
- text size of lables is calculated automaticly now
tested under fBSD only...
Created attachment 1151
fixed by patch
A bug with patches that is resolved, without /me looking at it.
Any chance of this patch getting committed?
I will apply them, test and release next week.
Ok I'm sorry to say this Alexey, but the patch is a mess. It might or might not solve the problem, but it's completely unreadable and I'm not going to apply a patch which I'm not 100% sure that it works on all the Unixes the plugin supports.
Oh man, don't say sorry to me.. it's ok.. just want to say some things.
first of all, I've said already that it's tested under fBSD only.. even not `tested' but `written under/for' it... cauze have only this OS.
yeah, the patch quite large and may seems to be a mess or whatever else... I perfectly understand that reading not your own code is most complicated thing...
but, you know, things doesn't depend on our opinions of it.. it just is...
everything what I know are:
1. 'battery' plugin has a very unoptimised code
2. my patch makes some optimisation under my system... it's just one of much ways in this area of course
3. it works for me (see earlier posts with numeric results)
don't have enough time to fix it for all systems.
just want to share it with the community. and it's your decision to accept it or to decline..
The patch is indeed a terrible mess, it's unreadable. The original code isn't that clear either, and it seems there's a lot of g_timeout_add() calls, I don't know if some of them don't overlap.
Alexey, woult it be possible to clean the patch and split it into multiple simple and independant parts?
It seems that the high cpu usage may be due to the gtk progress bar.
If you comment out gtk_progress_bar_set_fraction() in battery.c, it drops down and the plugin isn't constantly polling.
Having progress bar to show constant informations may not be a really good idea, finally. I don't know what will be the correct solution:
- disabling progress bars as a configuration option
- remove completely progress bar and find another way to display information
Regards, and thanks for your work,
It seems that the update logic doesn't work as expected. I noticed that when the battery is full the percent value jumps randomly between 99 and 100 percent. This is probably due to my buggy battery controller, but anyway it says that battery status update happen every 1-2 sec for some reason. Changing ALL timeouts in g_timeout_add calls to 30 seconds fixes the CPU issue for me.
-- 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-battery-plugin/-/issues/1.
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