1210784 - Codepen page with 3d transform animations does not repaint (unless resized)

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Patrick Brosset <:pbro>]

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.

Comment 1

[Patrick Brosset <:pbro>]

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

Comment 2

[u279076]

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

Comment 3

[u279076]

[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.

Comment 4

[Alice0775 White]

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)

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What was the needinfo? to me for?

Comment 6

[Thinker Li [:sinker]]

I would look into this.

Comment 7

[Kate Glazko]

Tracking for 44 nightly because regression with potential user impact.

Comment 8

[Thinker Li [:sinker]]

Attachment: Layer tree invalidation with Preserves3D

Comment 9

[Thinker Li [:sinker]]

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

Comment 10

[Patrick Brosset <:pbro>]

(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!

Comment 11

[Ryan VanderMeulen [:RyanVM]]

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

Comment 12

[Ryan VanderMeulen [:RyanVM]]

bug 1211360 rather

Comment 13

[Ryan VanderMeulen [:RyanVM]]

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

Comment 14

[Thinker Li [:sinker]]

Attachment: Layer tree invalidation with Preserves3D, v2

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

Comment 15

[Thinker Li [:sinker]]

Attachment: Layer tree invalidation with Preserves3D, v3

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

Comment 16

[Thinker Li [:sinker]]

Attachment: Layer tree invalidation with Preserves3D, v4

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

Comment 17

[Thinker Li [:sinker]]

Attachment: Layer tree invalidation with Preserves3D, v5

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

Comment 18

[Thinker Li [:sinker]]

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 19

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 20

[Thinker Li [:sinker]]

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

Comment 21

[Ryan VanderMeulen [:RyanVM]]

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

Comment 22

[Ryan VanderMeulen [:RyanVM]]

[Tracking Requested - why for this release]:

Comment 23

[Thinker Li [:sinker]]

Attachment: Layer tree invalidation with Preserves3D, v5

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

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Attachment: threejs screenshot

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.

Comment 25

[Thinker Li [:sinker]]

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.

Comment 26

[Loic]

Attachment: 3D-cube-testcase.htm

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

Comment 27

[Thinker Li [:sinker]]

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

Comment 29

[Thinker Li [:sinker]]

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 30

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8682295 [details] [diff] [review]
Layer tree invalidation with Preserves3D, v5

This doesn't apply to m-c tip. Please rebase.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Nevermind, it applies on top of bug 1208673.

Comment 32

[Ryan VanderMeulen [:RyanVM]]

Attachment: log w/ frame layer dumping enabled

(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 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 34

[Thinker Li [:sinker]]

(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.

Comment 35

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/28033d08c40b

Comment 36

[Thinker Li [:sinker]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=34c96635f70e

Comment 37

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/28033d08c40b

Comment 38

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Sinker, does this need to be uplifted to Aurora44?

Comment 40

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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

Comment 41

[Thinker Li [:sinker]]

yes

Comment 42

[Thinker Li [:sinker]]

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]:

Comment 43

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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

Comment 44

[Ryan VanderMeulen [:RyanVM]]

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 45

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 46

[Patrick Brosset <:pbro>]

(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.

Comment 48

[Ryan VanderMeulen [:RyanVM]]

This along with the change that caused this regression were backed out from Firefox 45.

https://hg.mozilla.org/releases/mozilla-aurora/rev/64ec448f156d