Project Candle bug triage (6th October 2015)

[Nicholas Nethercote]

Greetings,

This is Project Candle bug triage email. The process used is described at
https://wiki.mozilla.org/Performance/Project_Candle#Bug_triage_process.

At the time of writing there are 36 unprioritized Power bugs, viewable
at http://mzl.la/1VyfsCC. In this thread I am discussing 10 of the
more recent ones.


* https://bugzilla.mozilla.org/show_bug.cgi?id=972473
* High power consumption with Google+ button

Due to an SVG animation, seemingly. I wonder if this is covered by any of our
existing animation bugs.

bbirtles, any idea? I suggest P2 if not.


* https://bugzilla.mozilla.org/show_bug.cgi?id=972482
* High energy consumption in SVG animation (with animateTransform)

Another animation one.

I suggest P2.


* https://bugzilla.mozilla.org/show_bug.cgi?id=973591
* irccloud makes idle service come back from idle after 2 to 5 minutes

I know nothing about the idle service and so don't have much idea here.
Suggestions?


* https://bugzilla.mozilla.org/show_bug.cgi?id=976058
* Reduce wakeup overhead due to spinning wheel on tab load

Seems worthwhile.

I suggest P2.


* https://bugzilla.mozilla.org/show_bug.cgi?id=978134
* Stop blinking cursor in text box after N seconds of inactivity

Doesn't seem like that big a deal to me, and there's the uncertainty over the
accessibility effects.

I suggest P3.


* https://bugzilla.mozilla.org/show_bug.cgi?id=979121
* Re-filter URL bar search results in-memory

I have no opinion on this one.

I suggest P2 because it's the default.


* https://bugzilla.mozilla.org/show_bug.cgi?id=979916
* OMTC Windows: slightly higher power usage

The measurements are old and it's unlikely that we'd disable OMTC, so I'm not
sure what to do with this one. Close it?


* https://bugzilla.mozilla.org/show_bug.cgi?id=984961
* CSS animation consumes a significant amount of power at 163.com

We're hammering the GPU on this tiny animation.

I suggest P1 because 163.com is the #105 site in the world, slightly higher
than Buzzfeed, for which we have a P1 bug.


* https://bugzilla.mozilla.org/show_bug.cgi?id=986552
* Slightly higher power consumption on Instagram homepage

We are a little worse, but the login page is not interesting because people
don't actually spend time there.

I suggest closing the bug as uninteresting, or morphing it to be about a more
representative usage of Instagram (which is the #26 site in the world according
to Alexa); we'd have to get new measurements there. Any suggestions of what
that usage would look like?


* https://bugzilla.mozilla.org/show_bug.cgi?id=1178141
* Animated background image behind other layers is being needlessly
painted/repainted

Yet another animation power bug. Again, I don't know if this overlaps with any
existing ones.

I suggest P2 if it doesn't overlap.

[Thomas Daede]

> * https://bugzilla.mozilla.org/show_bug.cgi?id=972473

> * https://bugzilla.mozilla.org/show_bug.cgi?id=976058

These two really need average power measurements to get an idea about
what priority to assign them.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=979121
> * Re-filter URL bar search results in-memory

Seems to be a big usability impact, do users really spend enough time in
the awesome bar for this to save significant power?

>
> * https://bugzilla.mozilla.org/show_bug.cgi?id=979916
> * OMTC Windows: slightly higher power usage
>
> The measurements are old and it's unlikely that we'd disable OMTC, so I'm not
> sure what to do with this one. Close it?

I agree, and the power measurements look pretty sketchy (1.5W?)

[Brian Birtles]

On 2015/10/06 7:53, Nicholas Nethercote wrote:
> * https://bugzilla.mozilla.org/show_bug.cgi?id=972473
> * High power consumption with Google+ button
>
> Due to an SVG animation, seemingly. I wonder if this is covered by any of our
> existing animation bugs.
>
> bbirtles, any idea? I suggest P2 if not.

We haven't optimized SVG animation as much as CSS animation and I'm not
sure if we ever will now that Chrome is deprecating it (originally I had
hoped to switch SVG animation over to re-use the CSS animation code but
that seems hard to justify now).

If this is Google content, I imagine they'll switch to CSS animation
soon (the content in question could already be represented with CSS
animation unlike some other cases such as the SVG animation on YouTube).

As a result, I wonder if this is worth fixing. Perhaps P3?

> * https://bugzilla.mozilla.org/show_bug.cgi?id=972482
> * High energy consumption in SVG animation (with animateTransform)
>
> Another animation one.
>
> I suggest P2.

Comparing the test cases, this appears to be a dupe of the previous bug.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1178141
> * Animated background image behind other layers is being needlessly
> painted/repainted
>
> Yet another animation power bug. Again, I don't know if this overlaps with any
> existing ones.

I *think* the current strategy suggested for bug 1166500 might cover
this, but I'm not entirely sure.

> I suggest P2 if it doesn't overlap.

I agree.

[Kan-Ru Chen (陳侃如)]

Nicholas Nethercote <n.neth...@gmail.com> writes:

> * https://bugzilla.mozilla.org/show_bug.cgi?id=973591
> * irccloud makes idle service come back from idle after 2 to 5 minutes
>
> I know nothing about the idle service and so don't have much idea here.
> Suggestions?

While it's bad that content could affect idle status of the browser, I
don't think it affects power consumption that much. The only downside is
if we throttle some activities (animations, maybe?) when the browser is
idle, it won't happen. But we are not throttling based on that currently
so I suggest P3.

Kanru

[Mark Finkle]

On Mon, Oct 5, 2015 at 7:08 PM, Thomas Daede <tda...@mozilla.com> wrote:

> * https://bugzilla.mozilla.org/show_bug.cgi?id=979121
> * Re-filter URL bar search results in-memory

Seems to be a big usability impact, do users really spend enough time in
the awesome bar for this to save significant power?

They might. The awesomebar is used a lot. This is a tricky bug in some ways, since we'd want to make sure that we have *all* possible records in the cursor, even those for future, more specific searches. P2 sounds fine though.

[Richard Newman]

> * https://bugzilla.mozilla.org/show_bug.cgi?id=979121
> * Re-filter URL bar search results in-memory

Seems to be a big usability impact, do users really spend enough time in
the awesome bar for this to save significant power?

They might. The awesomebar is used a lot. This is a tricky bug in some ways, since we'd want to make sure that we have *all* possible records in the cursor, even those for future, more specific searches. P2 sounds fine though.

The usability impact would be an improvement in the responsiveness of the awesomebar, which I concur is more significant than the power saving.

To Mark's point, we'd only refilter when the new string is a superset of the previous string and the set of results is smaller than the threshold.

I don't know what the cumulative savings are from a power perspective — compared to playing video with the screen on it's a drop in the bucket, but building and running a new SQL query for each keypress does show up noticeably in real-time power monitoring. Enough drops fill the bucket.

P2 sounds fine to me.

[Nicholas Nethercote]

Thank you all for the discussion.

On Mon, Oct 5, 2015 at 3:53 PM, Nicholas Nethercote
<n.neth...@gmail.com> wrote:
>
> * https://bugzilla.mozilla.org/show_bug.cgi?id=972473
> * High power consumption with Google+ button
>
> Due to an SVG animation, seemingly. I wonder if this is covered by any of our
> existing animation bugs.
>
> bbirtles, any idea? I suggest P2 if not.

I did P3 because bbirtles said SVG animations are low priority.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=972482
> * High energy consumption in SVG animation (with animateTransform)
>
> Another animation one.
>
> I suggest P2.

I dup'd it to bug 972473 as bbirtles suggested.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=973591
> * irccloud makes idle service come back from idle after 2 to 5 minutes
>
> I know nothing about the idle service and so don't have much idea here.
> Suggestions?

I did P3 as Kan-Ru suggested.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=976058
> * Reduce wakeup overhead due to spinning wheel on tab load
>
> Seems worthwhile.
>
> I suggest P2.

I did P2.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=978134
> * Stop blinking cursor in text box after N seconds of inactivity
>
> Doesn't seem like that big a deal to me, and there's the uncertainty over the
> accessibility effects.
>
> I suggest P3.

I did P3.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=979121
> * Re-filter URL bar search results in-memory
>

> I have no opinion on this one.
>
> I suggest P2 because it's the default.

I did P2 with mfinkle and rnewman's blessing.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=979916
> * OMTC Windows: slightly higher power usage
>
> The measurements are old and it's unlikely that we'd disable OMTC, so I'm not
> sure what to do with this one. Close it?

I closed it, as Thomas suggested.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=984961
> * CSS animation consumes a significant amount of power at 163.com
>
> We're hammering the GPU on this tiny animation.
>
> I suggest P1 because 163.com is the #105 site in the world, slightly higher
> than Buzzfeed, for which we have a P1 bug.

I did P1.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=986552
> * Slightly higher power consumption on Instagram homepage
>
> We are a little worse, but the login page is not interesting because people
> don't actually spend time there.
>
> I suggest closing the bug as uninteresting, or morphing it to be about a more
> representative usage of Instagram (which is the #26 site in the world according
> to Alexa); we'd have to get new measurements there. Any suggestions of what
> that usage would look like?

I closed it.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1178141
> * Animated background image behind other layers is being needlessly
> painted/repainted
>
> Yet another animation power bug. Again, I don't know if this overlaps with any
> existing ones.
>

> I suggest P2 if it doesn't overlap.

I did P2, and mentioned in the bug that it might overlap with bug 1166500.