Tk Source Code

Hi,
if you run the widget demo Scales and Progress Bars/4.Progress bar you can observe that CPU is climbing.
It's because of the one in -mode indeterminate 

here on my computer Wish is using 3% of the CPU, but when this demo is launched, CPU is going up to 11%
If I edit the demo script and remove any ref to the ttk::progressbar in -mode indeterminate, CPU is 3%

it can be felt like a minor CPU usage but in a large app, CPU is raising more and lead to big lag...

this is why I've set severity to important.

best regards,
nicolas

Fixed [414d5d8863366522|here], backported to core-9-0-branch

While the patch doesn't show measurable improvement
It also doesn't do any harm and it does make sense
and apparently it helps on Linux. So I will go ahead
and merge it when I am able to do that later.

The 5% CPU is with the demo activated. When the demo 
window is open but the progress bars are not activated
and the mouse is not moving CPU usage is well under 1%.

The patch only stops the animation of an indeterminate progressbar which is not started, the case Nicolas described ("you don't have to start the ttk::progressbar"). Since [ea571a1307] such a progressbar is redrawn every -period milliseconds (100 in the aqua theme) forever. This can be checked without measuring CPU: the timer increments -phase.

ttk::style configure TProgressbar -period 100 -maxphase 120
ttk::progressbar .p -mode indeterminate
pack .p
after 2000 {puts [.p cget -phase]}

Without the patch it prints about 20, with the patch 0. On Linux with this setting the stopped progressbar takes 0.21 s of CPU in 20 s without the patch, and nothing with it; with -period 10 1.8 s.

If the demo still takes 5% of CPU on macOS with the patch and nothing started, it should have another cause.

I tested this patch by running the "Progress Bar" demo while checking CPU usage
with Activity Monitor.  The patch made no difference.  With or without the
patch the %CPU value was:
< 1% with no activity
~2%  while the mouse is moving
~5%  when running the Progress Bar demo with no mouse activity.

It is not clear to me that this is a regression nor that the patch does
anything to reduce CPU usage while a progress bar is running.

This is a regression from [ea571a1307] (for [ef1bfef57e]): it dropped the check of the value in AnimationEnabled(), so an indeterminate progressbar is animated even when it is not started, if the style sets -period.

Proposed fix in branch ttk-progressbar-stopped-animation: animate an indeterminate progressbar only while its value is positive, as before. Determinate progressbars are still not animated. New test progressbar-5.1.

I would suggest not showing a progress bar at all when there is nothing
to wait for.  When the wait starts, meaning that some expensive, long-
running operation is under way, then it would make sense to display a
progress bar as a courtesy to the user.  The extra CPU load from the
progress bar will not be so noticeable, since the CPU load is already
high.

ok,
so for now I've removed them all from my code.

++

In general, Ttk widgets are redrawn very frequently.  Every change of state,
e.g. a mouse Enter or Leave event, triggers a redraw.  Perhaps the progress
bar is regarded by Ttk as changing state whenever the animation timer fires
even if the appearance doesn't actually change, for example when the
progress bar is stopped.

With the progress bar widget demo I see < 1% cpu when the main demo window
is open, about 7% when the progress bar demo dialog is open but the progress
is stopped, and about 16% when the progress bars are started.  I added a print
statement in the generic display proc TtkWidgetDisplay so I could track
how often it is called.  I found that when the progress bar demo dialog is
open, with the progress bars stopped, there are well over 10 calls per 
second to TtkWidgetDisplay.  So that accounts for the CPU usage.  For some
reason Ttk thinks that the progress bar state changes more than 10 times
per second even when it is not running.  And each state change requires a
redraw.

I have no idea why it works that way but I seriously doubt that anything
that basic in the Ttk implementation has been changed since last July.

Hi Marc,
thank you for your answer, but what I meant is that you don't have to start the ttk::progressbar to grow up CPU.
I do observe CPU growing on the macOS only by gridding it !! (and some users of my app on Windows does observe the same thing)

AFAIK it was not the case in July 2024

best regards,
Nicolas

Yes, this has been the case for a long time.  Presumably it has to do with
the way that the animation is being handled on macOS.

I'm not seeing this behavior on Windows. CPU usage climbs from 0% to 0.1% for tclsh running the demo.

I forgot to say… CPU is raising when the ttk::progressbar is displayed. No need to run it.

++