Closed Bug 1020556 Opened 7 years ago Closed 7 years ago

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


(Core :: Graphics: Layers, defect)

Not set



Tracking Status
firefox30 --- unaffected
firefox31 --- unaffected
firefox32 + wontfix
firefox33 --- fixed


(Reporter: cpeterson, Assigned: mstange)




(Keywords: regression)


(2 files, 1 obsolete file)

1. Load

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:
Markus: does this bug look like a regression from bug 1008301 or bug 1008578 from this regression range?
Flags: needinfo?(mstange)
Bug 1008301 is a very likely candidate.
Assignee: nobody → mstange
Blocks: 1008301
Flags: needinfo?(mstange)
I can't reproduce this bug in today's nightly. Is this on Mac? Hardware acceleration on?
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.
I could reproduce this with the nightly from 06/05, but not from 06/06.
I can still reproduce this on my MacBook Pro with today's Nightly build (2014-06-06).
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.
Flags: needinfo?(dbaron)
Actually, Markus is already on the bug.
Flags: needinfo?(dbaron)
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.
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.
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.
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.
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.
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?
Flags: needinfo?(mstange)
Flags: needinfo?(milan)
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?
Flags: needinfo?(milan) → needinfo?(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.
Flags: needinfo?(tnikkel)
(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:
Flags: needinfo?(mstange)
Attached file testcase
Attachment #8437227 - Attachment is obsolete: true
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.
Blocks: 1008915
No longer blocks: 1008301
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.
Attachment #8450996 - Flags: review?(matt.woodrow)
Attachment #8450996 - Flags: review?(matt.woodrow) → review+

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.
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Depends on: 1187199
No longer depends on: 1187199
You need to log in before you can comment on or make changes to this bug.