Closed Bug 995287 Opened 10 years ago Closed 10 years ago

Static completed progressbar triggers 20 FPS recomposites

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla32

People

(Reporter: BenWa, Assigned: mstange)

Details

(Keywords: power)

Attachments

(2 files, 1 obsolete file)

Attached file progress.html
Tested on mac. A progress bar, even if it's hidden behind another element, triggers 20 FPS re-composite draining my battery.
Is this a dupe of bug 962594?
No, we also recomposite at 20 FPS when the progressbar is visible not animated on mac.
Attachment #8421916 - Flags: review?(bgirard)
huh, tabs... I'll fix the whitespace on checkin.
Comment on attachment 8421916 [details] [diff] [review]
dont repaint completed progressbars

Review of attachment 8421916 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/cocoa/nsNativeThemeCocoa.mm
@@ +2401,5 @@
> +    {
> +      double value = GetProgressValue(aFrame);
> +      double maxValue = GetProgressMaxValue(aFrame);
> +      // Don't request repaints for scrollbars at 100% because those don't animate.
> +      if (value < maxValue && !QueueAnimatedContentForRefresh(aFrame->GetContent(), 30)) {

I really don't like on relying on short circuit to avoid a function call. It much easier to understand:

if (value < maxValue)
  if (!QueueAnimatedContentForRefresh(aFrame->GetContent(), 30))
Attachment #8421916 - Flags: review?(bgirard) → review+
Good point.
Attachment #8421916 - Attachment is obsolete: true
Assignee: nobody → mstange
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/1d6d1d760d02
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: