Overview
Artifact ID: | f2d16bb6bff94028cc879badd0f3141bcb26ad25d3cd18d39fef9ce53872c14c |
---|---|
Ticket: | ef1bfef57e05099e93f1eb0960e658def076e424
Error in computing return value of AnimationEnabled for ttk progress bar |
User & Date: | marc_culler 2025-03-06 03:09:54 |
Changes
- assignee changed to: "nobody"
- closer changed to: "nobody"
- cmimetype changed to: "text/x-markdown"
- comment changed to:
I noticed an amazing bug in the implementation of the ttk progress bar when I was looking into [7e28ef577a]. When the loop incrementing the progress bar reached the end, the progress bar was rapidly redisplayed even though nothing was changing. (The value at the end of the loop was 99.) It turned out that AnimationEnabled was returning 1 even though the progress bar was determinate. The cause was a misplaced parenthesis dating back to 2006. The effect is to make any determinate progress bar be animated almost all of the time. This may explain, at least partly, the reports that progress bars significantly increase CPU usage even when they are not doing anything. Here is the problematic code: ``` return pb->progress.period > 0 && value > 0.0 && ( value < maximum || pb->progress.mode == TTK_PROGRESSBAR_INDETERMINATE); ``` The correct code (with extra parentheses for clarity) would be: ``` return (pb->progress.period > 0 && value > 0.0 && value < maximum) || (pb->progress.mode == TTK_PROGRESSBAR_INDETERMINATE); ```
- foundin changed to: "9.0.1"
- is_private changed to: "0"
- login: "marc_culler"
- priority changed to: "5 Medium"
- private_contact changed to: "4a267845b96d18ced148980dad8c23b791785018"
- resolution changed to: "None"
- severity changed to: "Important"
- status changed to: "Open"
- submitter changed to: "marc_culler"
- subsystem changed to: "88. Themed Tk"
- title changed to:
Error in computing return value of AnimationEnabled for ttk progress bar
- type changed to: "Bug"