1020556 - Star Trek Stabilized CSS animation has many white flashes and invalidation artifacts

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Chris Peterson [:cpeterson]]

STR:
1. Load http://www.reddit.com/r/startrekstabilized

RESULT:
The page shakes using CSS magic, but there are many white flashes and invalidation artifacts.

This is a regression in Nightly 32 build 2014-05-14. I bisected mozilla-inbound builds from that day using mozregression and identified this regression range:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=971b840c40ff&tochange=35af5d1c97c3

Comment 1

[Chris Peterson [:cpeterson]]

Markus: does this bug look like a regression from bug 1008301 or bug 1008578 from this regression range?

Comment 2

[Markus Stange [:mstange]]

Bug 1008301 is a very likely candidate.

Comment 3

[Markus Stange [:mstange]]

I can't reproduce this bug in today's nightly. Is this on Mac? Hardware acceleration on?

Comment 4

[Chris Peterson [:cpeterson]]

I am using a Retina MacBook Pro. If I toggle the layers.acceleration.disabled pref from false (its default value) to true (and restart Firefox), then the rendering problem is no longer reproducible.

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

I could reproduce this with the nightly from 06/05, but not from 06/06.

Comment 6

[Chris Peterson [:cpeterson]]

I can still reproduce this on my MacBook Pro with today's Nightly build (2014-06-06).

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

I can now as well, with both 2014-06-06 and 2014-06-09.  Are we sure it isn't content?  The flashing seems to be the side div bouncing between two locations.  It may be useful for somebody from layout to comment.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

Actually, Markus is already on the bug.

Comment 9

[Markus Stange [:mstange]]

I still haven't had any luck reproducing this, and I've tried every day with each new nightly. If somebody who can reproduce it could attach a reduced form of the page as a testcase, that would be extremely helpful.

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: Simple(r) case to reproduce the problem

You should get a very simple html and two css files that I haven't even tried to simplify, but this case does reproduce the problem for me.

Comment 11

[Chris Peterson [:cpeterson]]

I can reproduce the bug with Milan's test case (comment 10) when the window is on my MacBook Pro's Retina display but not when I drag it to my external display.

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

I can definitely believe it's related to the device pixels vs. css pixels, as those items flash, their size and position would be "correct" if the two (device and css) would be the same, but on retina display they're not.

Comment 13

[Markus Stange [:mstange]]

I can finally reproduce it with today's nightly! :) Both in Milan's testcase and on the real page.
I think comment 12 is right on the money.

Comment 14

[Lawrence Mandel [:lmandel] (use needinfo)]

Milan/Markus - If comment 12 is on, does the issue live in gfx or layout? According to Chris this is a regression in 32. Can we pursue a fix in 32 to avoid shipping this regression?

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

Layout, I think Markus is the right person for it - Markus, let me know if you don't have the time for this, maybe Timothy can help?

Comment 16

[Timothy Nikkel (:tnikkel)]

I can definitely help, but I cannot reproduce the problem (with the original url or the testcase attached to this bug), since I don't have a retina display this makes sense based on comment 12.

Comment 17

[Markus Stange [:mstange]]

(In reply to Lawrence Mandel [:lmandel] from comment #14)
> Milan/Markus - If comment 12 is on, does the issue live in gfx or layout?

I haven't figured out yet.

> According to Chris this is a regression in 32. Can we pursue a fix in 32 to
> avoid shipping this regression?

I'm going to back out bug 1008301 (which caused this) on Aurora to give me more time to fix it.
Try push of backout: https://tbpl.mozilla.org/?tree=Try&rev=60b9f16e3037

Comment 18

[Markus Stange [:mstange]]

Attachment: testcase

Comment 19

[Markus Stange [:mstange]]

Interesting... two new facts have surfaced:
 1. The regression with the original reddit page was *not* due to bug 1008301, but due to bug 1008915.
 2. The testcase from comment 18 is broken even with builds before that.

Comment 20

[Markus Stange [:mstange]]

Attachment: increase tolerance

With 1e-6f, we were getting a scale factor of 2 for example for the transform rotate(-0.091deg). This patch increases the tolerance slightly so that we still nudge to 1 for this matrix and don't end up with an unnecessary scale.
In the testcase, a scale factor of 2 was causing the layer's visible region to become wider than the maximum texture size (4096) so we refused to paint it. We probably want to reduce the scale in those cases (or switch to tiling?) - but I'll leave that part to bug 1034247.

Comment 21

[Markus Stange [:mstange]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2b0123d6e00a

By the way, the reason that I couldn't reproduce this in the beginning was that I was running with the discrete GPU when Firefox started, so it chose a higher maximum texture size (8191 instead of 4096) because the GLContext mVendor was GLVendor::NVIDIA and not GLVendor::Intel.

Comment 22

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/2b0123d6e00a