STR: - use nightly (was using 43.0a2 (2015-09-30) myself) - open http://codepen.io/thebabydino/pen/oXVbmB - watch how only parts of the iframe get re-painted once in a while Now, to actually force it to repaint, you can resize the window. In fact, if you keep resizing the window very rapidly, you can see the animation.

This happens on many of Ana Tudor's demos on codepen, see http://codepen.io/thebabydino/full/pzgiE/ for example.

Looks like this is a regression. I will work with mozregression to find the range.

[Tracking Requested - why for this release] The regression was introduced in the Firefox Nightly 43.0a1 2015-09-19 build. > https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=11dc79e232110ba6de5179e46dfbda77b52a88c3&tochange=4313752f69956ae248bd4e7ff3913c8dd4252698 > https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7641104770a80015e63597b58cb312fefcbd9ab4&tochange=621ab19e86db28c38bbbf9119fbf6831ea344c54 Looks like bug 1097464 is to blame. What's strange is that was backed out on September 25th so this shouldn't be affecting the latest Aurora builds.

I can reproduce the repaint problem on Nightly44.0a1[A], but I can not reproduce on Aurora43.a2[B]. [A] https://hg.mozilla.org/mozilla-central/rev/5f16c6c2b969f70e8da10ee34853246d593af412 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 ID:20151002030204 [B] https://hg.mozilla.org/releases/mozilla-aurora/rev/0bb47dc85ea858f81831f14f46dfb2c8d510b4d9 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 ID:20151002004047 (I found z-order bug, see Bug 1210882)

What was the needinfo? to me for?

I would look into this.

Tracking for 44 nightly because regression with potential user impact.

Patrick, could you check if the last patch fix your issue.

(In reply to Thinker Li [:sinker] from comment #9) > Patrick, could you check if the last patch fix your issue. Built your patch on top of today's fx-team. The problem seems fixed. Thanks!

This or bug 1121360 appears to becausing reftest failures - https://treeherder.mozilla.org/logviewer.html#?job_id=12711639&repo=try

bug 1211360 rather

OSX build bustage too: https://treeherder.mozilla.org/logviewer.html#?job_id=12712060&repo=try

-- Attachment #8672389 [details] [diff] - Attachment is obsolete: true

-- Attachment #8675500 [details] [diff] - Attachment is obsolete: true

-- Attachment #8675543 [details] [diff] - Attachment is obsolete: true

-- Attachment #8676113 [details] [diff] - Attachment is obsolete: true

Comment on attachment 8676613 [details] [diff] [review] Layer tree invalidation with Preserves3D, v5 Ryan, I need you feed back for this patch for the bug 1214212.

Comment on attachment 8676613 [details] [diff] [review] Layer tree invalidation with Preserves3D, v5 Overall, this appears to work well in the threejs testcase. I still see a bar on the right side when the page loads that disappears after some indeterminate time, though. Seems easier to reproduce at larger window sizes.

Ryan, could you take a picture? I am not sure if I see the same picture.

Can you please attach a rebased patch for me to try out? The current one here is bitrotted.

[Tracking Requested - why for this release]:

-- Attachment #8676613 [details] [diff] - Attachment is obsolete: true

This is what it looks like immediately after page load. This is with a maximized browser window. The bars will eventually go away if you click and rotate the cube or change the window size.

Ryan, I can not reproduce it. What environment are you running on? If you can apply the patch https://bugzilla.mozilla.org/attachment.cgi?id=8676124 and the patch here, and give me the log, it would be very helpful. If there is any way that I can access your environment, it would be better.

A French user reported a similar issue with 3D cube on his website: http://www.visionduweb.fr/ Reduced testcase attached.

Loic, my experiment shows the patch on this bug can fix your case. Please confirm it! Thank you!

I find the patch here fix all relative cases, except the one mentioned by Ryan. I suspect that it differs from the bug here. I like to open another bug for Ryan's problem, and start to review the patch. What do you think?

Comment on attachment 8682295 [details] [diff] [review] Layer tree invalidation with Preserves3D, v5 This doesn't apply to m-c tip. Please rebase.

Nevermind, it applies on top of bug 1208673.

(In reply to Thinker Li [:sinker] from comment #25) > Ryan, I can not reproduce it. What environment are you running on? If you > can apply the patch https://bugzilla.mozilla.org/attachment.cgi?id=8676124 > and the patch here, and give me the log, it would be very helpful. If there > is any way that I can access your environment, it would be better. I'm on Win10 with a work-issued W530 laptop running on external monitors over the nVidia GPU. The attached log is from a debug build with the frame layer dumping patch applied. The profile was created with the threejs demo set as the home page to minimize the noise. The log consists of launching the browser, letting the page fully load (showing the bar down the right side), and immediately closing the browser.

Comment on attachment 8682295 [details] [diff] [review] Layer tree invalidation with Preserves3D, v5 Review of attachment 8682295 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/LayerTreeInvalidation.cpp @@ +45,5 @@ > + layer = layer->GetParent()) { > + transform = transform * layer->GetLocalTransform(); > + } > + return transform; > +} Isn't this code already existing somewhere else we can share?

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #33) > Comment on attachment 8682295 [details] [diff] [review] > Layer tree invalidation with Preserves3D, v5 > > Review of attachment 8682295 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: gfx/layers/LayerTreeInvalidation.cpp > @@ +45,5 @@ > > + layer = layer->GetParent()) { > > + transform = transform * layer->GetLocalTransform(); > > + } > > + return transform; > > +} > > Isn't this code already existing somewhere else we can share? Effective transform is what we want here, but we don't always create intermediate surface. We can remove effective transform of the root a 3D rendering context from the effective transform of the target layer by applying the reversed transform. But, it would be failed for singular matrices.

Sinker, does this need to be uplifted to Aurora44?

Ken, would you be able to help with comment 38? Thanks!

yes

Comment on attachment 8682295 [details] [diff] [review] Layer tree invalidation with Preserves3D, v5 Approval Request Comment [Feature/regressing bug #]: 1210784 [User impact if declined]: Content in a preserve3d sub-tree would be invalidated inccorrectly. [Describe test coverage new/current, TreeHerder]: https://treeherder.mozilla.org/#/jobs?repo=try&revision=34c96635f70e [Risks and why]: [String/UUID change made/needed]:

Patrick, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!

Bug 1097464 was backed out from Fx44, which should be available on the beta channel in the next day or so. Fx45+ remain affected, however.

Comment on attachment 8682295 [details] [diff] [review] Layer tree invalidation with Preserves3D, v5 A- due to the regressions and back outs caused by this one. Please see comment 44.

(In reply to Ritu Kothari (:ritu) from comment #43) > Patrick, could you please verify this issue is fixed as expected on a latest > Nightly build? Thanks! Works for me now.

This along with the change that caused this regression were backed out from Firefox 45. https://hg.mozilla.org/releases/mozilla-aurora/rev/64ec448f156d