searching for reviewer(ethlin)
9369c3cededfcab2b52c239ab3343b877d3e2820: Bug 1421888 - Don't apply highlight-painted-layers or paint-flashing fills when drawing mask surfaces. r=ethlin
Markus Stange <mstange@themasta.com> - Wed, 29 Nov 2017 23:28:54 -0500 - rev 706159
Push 91730 by choller@mozilla.com at Fri, 01 Dec 2017 12:27:59 +0000
Bug 1421888 - Don't apply highlight-painted-layers or paint-flashing fills when drawing mask surfaces. r=ethlin MozReview-Commit-ID: GfRkuBDly6f
977b9b0f80e01c7103cacadec2a53b838fb9f6f6: Bug 1421888 - Don't apply highlight-painted-layers or paint-flashing fills when drawing mask surfaces. r?ethlin draft
Markus Stange <mstange@themasta.com> - Wed, 29 Nov 2017 23:28:54 -0500 - rev 705463
Push 91476 by bmo:mstange@themasta.com at Thu, 30 Nov 2017 04:29:20 +0000
Bug 1421888 - Don't apply highlight-painted-layers or paint-flashing fills when drawing mask surfaces. r?ethlin MozReview-Commit-ID: GfRkuBDly6f
5bee2596ae4d3f0169039953182b792c2eba0c35: Bug 1415326. Tolerate slight changes in scale for fallback items. r=ethlin
Jeff Muizelaar <jmuizelaar@mozilla.com> - Fri, 10 Nov 2017 11:42:42 -0500 - rev 696681
Push 88760 by bgrinstead@mozilla.com at Fri, 10 Nov 2017 22:53:53 +0000
Bug 1415326. Tolerate slight changes in scale for fallback items. r=ethlin This helps us avoid rerasterizing the blob images every frame. This makes a huge difference in performance. Our score goes from approx 75 to 380. Current Firefox gets about 200.
e15cf10f369acd8129126525c349ade395abf876: Bug 1414097 - Convert nsDisplaySelectionOverlay to WebRender. r=ethlin
Markus Stange <mstange@themasta.com> - Thu, 02 Nov 2017 19:43:08 -0400 - rev 692631
Push 87552 by bmo:standard8@mozilla.com at Fri, 03 Nov 2017 10:21:12 +0000
Bug 1414097 - Convert nsDisplaySelectionOverlay to WebRender. r=ethlin MozReview-Commit-ID: 5icpe4OR0Qa
4ecf1d9c1975c76b41a5f9fbf564e8693b26fcd5: Bug 1409243 - Enable dotted and dashed border support for webrender; r=ethlin
Kevin Chen <kechen@mozilla.com> - Wed, 25 Oct 2017 10:17:41 +0800 - rev 692593
Push 87552 by bmo:standard8@mozilla.com at Fri, 03 Nov 2017 10:21:12 +0000
Bug 1409243 - Enable dotted and dashed border support for webrender; r=ethlin MozReview-Commit-ID: 4TGeavMJY2Q
d14886c6fc62a074ebebece45843364301214afb: Bug 1414097 - Convert nsDisplaySelectionOverlay to WebRender. r?ethlin draft
Markus Stange <mstange@themasta.com> - Thu, 02 Nov 2017 19:43:08 -0400 - rev 692356
Push 87474 by bmo:mstange@themasta.com at Thu, 02 Nov 2017 23:43:45 +0000
Bug 1414097 - Convert nsDisplaySelectionOverlay to WebRender. r?ethlin MozReview-Commit-ID: 5icpe4OR0Qa
3e544f192e88f14dc21734af59acbbea68d9a456: Bug 1409243 - Enable dotted and dashed border support for webrender; r?ethlin draft
Kevin Chen <kechen@mozilla.com> - Wed, 25 Oct 2017 10:17:41 +0800 - rev 691866
Push 87336 by bmo:kechen@mozilla.com at Thu, 02 Nov 2017 05:24:53 +0000
Bug 1409243 - Enable dotted and dashed border support for webrender; r?ethlin MozReview-Commit-ID: 4TGeavMJY2Q
8b76e07b21bc2b462dd93d40fdb1162cdd7dcdf6: Bug 1411856 - Make sure we add to the display list building area when marking a caret frame as invalid. r=ethlin
Matt Woodrow <mwoodrow@mozilla.com> - Thu, 26 Oct 2017 22:02:05 +1300 - rev 687125
Push 86419 by gszorc@mozilla.com at Thu, 26 Oct 2017 22:27:24 +0000
Bug 1411856 - Make sure we add to the display list building area when marking a caret frame as invalid. r=ethlin MozReview-Commit-ID: GA3pObvoPz3
546c2752c1fbff5757b6b946a5d09457b54dafe1: Bug 1411856 - Make sure we add to the display list building area when marking a caret frame as invalid. r?ethlin draft
Matt Woodrow <mwoodrow@mozilla.com> - Thu, 26 Oct 2017 22:02:05 +1300 - rev 686706
Push 86260 by mwoodrow@mozilla.com at Thu, 26 Oct 2017 09:02:38 +0000
Bug 1411856 - Make sure we add to the display list building area when marking a caret frame as invalid. r?ethlin MozReview-Commit-ID: GA3pObvoPz3
4d8523e883303346922488c85aa99ab940fe79d3: Bug 1409446 - Treat sticky clips as out-of-band clips. r=ethlin,mstange
Kartikaya Gupta <kgupta@mozilla.com> - Tue, 24 Oct 2017 15:46:00 -0400 - rev 685816
Push 86016 by kgupta@mozilla.com at Wed, 25 Oct 2017 01:53:44 +0000
Bug 1409446 - Treat sticky clips as out-of-band clips. r=ethlin,mstange MozReview-Commit-ID: C0KEuSrCPEQ
75e3a4777a7f7aeba2cea8bae4ff64c67712f578: Bug 1409446 - Modify the extra-clip flag to instead track more useful information. r=ethlin,mstange
Kartikaya Gupta <kgupta@mozilla.com> - Tue, 24 Oct 2017 15:45:59 -0400 - rev 685811
Push 86016 by kgupta@mozilla.com at Wed, 25 Oct 2017 01:53:44 +0000
Bug 1409446 - Modify the extra-clip flag to instead track more useful information. r=ethlin,mstange Instead of just keeping a count of how many "extra clips" (aka out-of-band clips) we have pushed, track more complex information for each clip. In particular, track the display item's normal clip chain, as well as the clip id of the extra clip that was pushed. This will be needed to override clip cache information in the next patch. MozReview-Commit-ID: AWKDTkelhyL
78ebffd42d32765a33bf64c094f0b9e1b47fee1b: Bug 1409446 - Treat sticky clips as out-of-band clips. r?ethlin,mstange draft
Kartikaya Gupta <kgupta@mozilla.com> - Tue, 24 Oct 2017 15:46:00 -0400 - rev 685552
Push 85968 by kgupta@mozilla.com at Tue, 24 Oct 2017 19:46:20 +0000
Bug 1409446 - Treat sticky clips as out-of-band clips. r?ethlin,mstange MozReview-Commit-ID: C0KEuSrCPEQ
323e68e0f83c86599b684fd0488e3a1c44b9f7e9: Bug 1409446 - Modify the extra-clip flag to instead track more useful information. r?ethlin,mstange draft
Kartikaya Gupta <kgupta@mozilla.com> - Tue, 24 Oct 2017 15:45:59 -0400 - rev 685547
Push 85968 by kgupta@mozilla.com at Tue, 24 Oct 2017 19:46:20 +0000
Bug 1409446 - Modify the extra-clip flag to instead track more useful information. r?ethlin,mstange Instead of just keeping a count of how many "extra clips" (aka out-of-band clips) we have pushed, track more complex information for each clip. In particular, track the display item's normal clip chain, as well as the clip id of the extra clip that was pushed. This will be needed to override clip cache information in the next patch. MozReview-Commit-ID: AWKDTkelhyL
f4f8721d812cac6f171a54418a1ef8fc919c02d8: Bug 1409446 - Treat sticky clips as out-of-band clips. r?ethlin,mstange draft
Kartikaya Gupta <kgupta@mozilla.com> - Mon, 23 Oct 2017 10:07:26 -0400 - rev 684818
Push 85739 by kgupta@mozilla.com at Mon, 23 Oct 2017 17:02:50 +0000
Bug 1409446 - Treat sticky clips as out-of-band clips. r?ethlin,mstange MozReview-Commit-ID: C0KEuSrCPEQ
4fd530d8af2040509ce78e57f1266c1df0a5086c: Bug 1409446 - Modify the extra-clip flag to instead track more useful information. r?ethlin,mstange draft
Kartikaya Gupta <kgupta@mozilla.com> - Mon, 23 Oct 2017 10:07:25 -0400 - rev 684813
Push 85739 by kgupta@mozilla.com at Mon, 23 Oct 2017 17:02:50 +0000
Bug 1409446 - Modify the extra-clip flag to instead track more useful information. r?ethlin,mstange Instead of just keeping a count of how many "extra clips" (aka out-of-band clips) we have pushed, track more complex information for each clip. In particular, track the display item's normal clip chain, as well as the clip id of the extra clip that was pushed. This will be needed to override clip cache information in the next patch. MozReview-Commit-ID: AWKDTkelhyL
f4bdfdb0c9828b256ee785cc2446e1bfb5508327: Bug 1409446 - Treat sticky clips as out-of-band clips. r?ethlin,mstange draft
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 19 Oct 2017 13:38:17 -0400 - rev 683421
Push 85375 by kgupta@mozilla.com at Thu, 19 Oct 2017 18:03:06 +0000
Bug 1409446 - Treat sticky clips as out-of-band clips. r?ethlin,mstange MozReview-Commit-ID: C0KEuSrCPEQ
4eb0961d74455f89e93f1d0fd1c63ec819f70e3f: Bug 1409446 - Modify the extra-clip flag to instead track more useful information. r?ethlin,mstange draft
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 19 Oct 2017 13:38:16 -0400 - rev 683416
Push 85375 by kgupta@mozilla.com at Thu, 19 Oct 2017 18:03:06 +0000
Bug 1409446 - Modify the extra-clip flag to instead track more useful information. r?ethlin,mstange Instead of just keeping a count of how many "extra clips" (aka out-of-band clips) we have pushed, track more complex information for each clip. In particular, track the display item's normal clip chain, as well as the clip id of the extra clip that was pushed. This will be needed to override clip cache information in the next patch. MozReview-Commit-ID: AWKDTkelhyL
0adf82c22dc1dd3515502810a74d979a06b73e24: Bug 1409446 - Treat sticky clips as out-of-band clips. r?ethlin,mstange draft
Kartikaya Gupta <kgupta@mozilla.com> - Tue, 17 Oct 2017 15:06:58 -0400 - rev 681707
Push 84915 by kgupta@mozilla.com at Tue, 17 Oct 2017 19:26:58 +0000
Bug 1409446 - Treat sticky clips as out-of-band clips. r?ethlin,mstange MozReview-Commit-ID: C0KEuSrCPEQ
c803a800a37badf924f956a217631be2ef293526: Bug 1409446 - Modify the extra-clip flag to instead track more useful information. r?ethlin,mstange draft
Kartikaya Gupta <kgupta@mozilla.com> - Tue, 17 Oct 2017 15:06:57 -0400 - rev 681702
Push 84915 by kgupta@mozilla.com at Tue, 17 Oct 2017 19:26:58 +0000
Bug 1409446 - Modify the extra-clip flag to instead track more useful information. r?ethlin,mstange Instead of just keeping a count of how many "extra clips" (aka out-of-band clips) we have pushed, track more complex information for each clip. In particular, track the display item's normal clip chain, as well as the clip id of the extra clip that was pushed. This will be needed to override clip cache information in the next patch. MozReview-Commit-ID: AWKDTkelhyL
e1cb1a770d6303ec6d5c2389130a4c10e2e32c9c: Bug 1403943 - Slightly increase fuzz again for test when webrender is enabled. r=ethlin
Kartikaya Gupta <kgupta@mozilla.com> - Mon, 16 Oct 2017 08:59:18 -0400 - rev 681236
Push 84788 by bmo:cam@mcc.id.au at Tue, 17 Oct 2017 04:58:36 +0000
Bug 1403943 - Slightly increase fuzz again for test when webrender is enabled. r=ethlin MozReview-Commit-ID: En4R2SZd8fW
810a616f84c64e404c4d9e195e5f5d3a46200344: Bug 1403943 - Slightly increase fuzz again for test when webrender is enabled. r?ethlin draft
Kartikaya Gupta <kgupta@mozilla.com> - Mon, 16 Oct 2017 08:59:18 -0400 - rev 680827
Push 84646 by kgupta@mozilla.com at Mon, 16 Oct 2017 12:59:36 +0000
Bug 1403943 - Slightly increase fuzz again for test when webrender is enabled. r?ethlin MozReview-Commit-ID: En4R2SZd8fW
38aba5843d79d421d1082bcde16d5d2124f689c3: Bug 1349067 - Make gl as current at WebGL2 ReadBuffer(); r=ethlin,jgilbert
Daosheng Mu <daoshengmu@gmail.com> - Tue, 28 Mar 2017 00:05:37 +0800 - rev 678445
Push 83926 by bmo:cnevinchen@gmail.com at Wed, 11 Oct 2017 10:32:10 +0000
Bug 1349067 - Make gl as current at WebGL2 ReadBuffer(); r=ethlin,jgilbert MozReview-Commit-ID: 5yrsuhilb1N
eaaaba7a4a80a07be528b17eaaf33a325b51aa1b: Bug 1406119 - Ensure that we do all the necessary APZ prep before recursing. r=ethlin
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 05 Oct 2017 13:20:57 -0400 - rev 676428
Push 83480 by bmo:emilio@crisal.io at Sat, 07 Oct 2017 12:44:35 +0000
Bug 1406119 - Ensure that we do all the necessary APZ prep before recursing. r=ethlin Bug 1404782 added another codepath that allows the CreateWebRenderCommandsFromDisplayList function to recurse. However recursion is tricky when APZ is enabled because we need to do a bunch of setup and teardown to properly build event regions and track APZ state. This patch moves the new recursion codepath inside the setup and teardown, so that it works as intended. MozReview-Commit-ID: C2Pwld7DdCC
1fe26ac4c4bf015fd364a5fca68ef919562d0511: Bug 1406119 - Ensure that we do all the necessary APZ prep before recursing. r?ethlin draft
Kartikaya Gupta <kgupta@mozilla.com> - Fri, 06 Oct 2017 09:29:45 -0400 - rev 676024
Push 83367 by kgupta@mozilla.com at Fri, 06 Oct 2017 13:30:14 +0000
Bug 1406119 - Ensure that we do all the necessary APZ prep before recursing. r?ethlin Bug 1404782 added another codepath that allows the CreateWebRenderCommandsFromDisplayList function to recurse. However recursion is tricky when APZ is enabled because we need to do a bunch of setup and teardown to properly build event regions and track APZ state. This patch moves the new recursion codepath inside the setup and teardown, so that it works as intended. MozReview-Commit-ID: KolCIbuBAyG
7b53d3faa8dbe88c8fdf1bbd1a75a1a6c43aeb07: Bug 1406119 - Ensure that we do all the necessary APZ prep before recursing. r?ethlin draft
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 05 Oct 2017 13:20:57 -0400 - rev 675685
Push 83197 by kgupta@mozilla.com at Thu, 05 Oct 2017 17:21:13 +0000
Bug 1406119 - Ensure that we do all the necessary APZ prep before recursing. r?ethlin Bug 1404782 added another codepath that allows the CreateWebRenderCommandsFromDisplayList function to recurse. However recursion is tricky when APZ is enabled because we need to do a bunch of setup and teardown to properly build event regions and track APZ state. This patch moves the new recursion codepath inside the setup and teardown, so that it works as intended. MozReview-Commit-ID: C2Pwld7DdCC
3baddc8863b2898efff2f52db657e5d997ebf1b5: Bug 1403642. Avoid an extra property table lookup. r=ethlin
Jeff Muizelaar <jmuizelaar@mozilla.com> - Fri, 29 Sep 2017 00:39:55 -0400 - rev 672504
Push 82272 by hikezoe@mozilla.com at Fri, 29 Sep 2017 10:18:13 +0000
Bug 1403642. Avoid an extra property table lookup. r=ethlin We can just call Get() and check the return value instead of calling Has()
f1cbf53a14ea8553ce4edb947b4a28d24c08b088: Bug 1400888 - Mark some transform-3d reftests intermittently fuzzy in layers-free webrender. r=ethlin
Kartikaya Gupta <kgupta@mozilla.com> - Mon, 18 Sep 2017 13:20:35 -0400 - rev 667236
Push 80655 by felipc@gmail.com at Tue, 19 Sep 2017 21:57:38 +0000
Bug 1400888 - Mark some transform-3d reftests intermittently fuzzy in layers-free webrender. r=ethlin MozReview-Commit-ID: FCE7OIPN3Vy
2a0c39ba138bed7987ebecca889934220ca3546a: Bug 1400888 - Turn on layers-free for transform/ and transform-3d/ reftests. r=ethlin
Kartikaya Gupta <kgupta@mozilla.com> - Mon, 18 Sep 2017 13:20:34 -0400 - rev 667235
Push 80655 by felipc@gmail.com at Tue, 19 Sep 2017 21:57:38 +0000
Bug 1400888 - Turn on layers-free for transform/ and transform-3d/ reftests. r=ethlin MozReview-Commit-ID: 9xAeMDcfHNK
1e2233c98ff1e88570cf61b52ee3bf57e39950df: Bug 1400034 - Turn on layers-free for transform/ and transform-3d/ reftests. r=ethlin,pchang
Kartikaya Gupta <kgupta@mozilla.com> - Sun, 17 Sep 2017 10:37:43 -0400 - rev 666550
Push 80461 by ktomlinson@mozilla.com at Mon, 18 Sep 2017 23:48:05 +0000
Bug 1400034 - Turn on layers-free for transform/ and transform-3d/ reftests. r=ethlin,pchang MozReview-Commit-ID: Ae80DrMwg1X
5524d88599f61ecbf0b85287e760939f4634001b: Bug 1400034 - Do a more direct translation of transforms from Gecko to WR in layers-free mode. r=ethlin,pchang
Kartikaya Gupta <kgupta@mozilla.com> - Sun, 17 Sep 2017 10:37:43 -0400 - rev 666549
Push 80461 by ktomlinson@mozilla.com at Mon, 18 Sep 2017 23:48:05 +0000
Bug 1400034 - Do a more direct translation of transforms from Gecko to WR in layers-free mode. r=ethlin,pchang In layers-free mode the gecko display list and coordinate system is very similar to what WR is expecting. Instead of having each StackingContextHelper shift the origin of the coordinate system, we can leave it in one spot and just pass everything relative to that. The semantics of the Gecko display list already matches this; the exception is that nsDisplayTransform items are also considered reference frames, and anything inside them is relative to the nsDisplayTransform. On the WR side this is also the case, because stacking contexts with a transform are implicitly turned into reference frames. Additionally, the size of the bounds passed to the WR stacking context is never actually used, except on the root stacking context (which is not created by StackingContextHelper). Since we want a zero origin (as explained above) and the size is never used, we can just pass a zero rect to the WR stacking context from StackingContextHelper. In terms of the actual transform matrix, this patch now passes the full unmodified transform from nsDisplayTransform into WR. This transform gets applied onto the contents of the nsDisplayTransform. The contents' coordinate system is relative to the frame that generated the nsDisplayTransform. Again this maps directly to WR, where the transform on the stacking context gets applied to the contents of the stacking context; the contents' coordinates are relative to the stacking context. MozReview-Commit-ID: 9hdDxdKXPPi
cd9baf0faf83aae1fad11be37bacc341f7316cef: Bug 1400034 - Back out changes that introduce scaling complexity to StackingContextHelper. r=ethlin,pchang
Kartikaya Gupta <kgupta@mozilla.com> - Sun, 17 Sep 2017 10:37:42 -0400 - rev 666548
Push 80461 by ktomlinson@mozilla.com at Mon, 18 Sep 2017 23:48:05 +0000
Bug 1400034 - Back out changes that introduce scaling complexity to StackingContextHelper. r=ethlin,pchang This backs out bug 1399050, bug 1394308 (2 patches), and bug 1391499. I believe these patches sent us down a path that would make the code increasingly more complex, when in fact we can do a more "direct" translation from the gecko display list to the WR display list and make things a lot simpler and more correct. MozReview-Commit-ID: ZXXkI9DXiY
2bfa263ac3c7cbc7305c14f92b6407371d12c69a: Bug 1400888 - Mark some transform-3d reftests intermittently fuzzy in layers-free webrender. r?ethlin draft
Kartikaya Gupta <kgupta@mozilla.com> - Mon, 18 Sep 2017 13:20:35 -0400 - rev 666366
Push 80384 by kgupta@mozilla.com at Mon, 18 Sep 2017 17:20:57 +0000
Bug 1400888 - Mark some transform-3d reftests intermittently fuzzy in layers-free webrender. r?ethlin MozReview-Commit-ID: FCE7OIPN3Vy
7a279a5309e00c74708e8b7c5b87d9db08278126: Bug 1400888 - Turn on layers-free for transform/ and transform-3d/ reftests. r=ethlin draft
Kartikaya Gupta <kgupta@mozilla.com> - Mon, 18 Sep 2017 13:20:34 -0400 - rev 666365
Push 80384 by kgupta@mozilla.com at Mon, 18 Sep 2017 17:20:57 +0000
Bug 1400888 - Turn on layers-free for transform/ and transform-3d/ reftests. r=ethlin MozReview-Commit-ID: 9xAeMDcfHNK
53414291e0321608f2ce12e919aec9497ea6a6da: Bug 1400034 - Do a more direct translation of transforms from Gecko to WR in layers-free mode. r?ethlin,pchang draft
Kartikaya Gupta <kgupta@mozilla.com> - Mon, 18 Sep 2017 13:20:33 -0400 - rev 666363
Push 80384 by kgupta@mozilla.com at Mon, 18 Sep 2017 17:20:57 +0000
Bug 1400034 - Do a more direct translation of transforms from Gecko to WR in layers-free mode. r?ethlin,pchang In layers-free mode the gecko display list and coordinate system is very similar to what WR is expecting. Instead of having each StackingContextHelper shift the origin of the coordinate system, we can leave it in one spot and just pass everything relative to that. The semantics of the Gecko display list already matches this; the exception is that nsDisplayTransform items are also considered reference frames, and anything inside them is relative to the nsDisplayTransform. On the WR side this is also the case, because stacking contexts with a transform are implicitly turned into reference frames. Additionally, the size of the bounds passed to the WR stacking context is never actually used, except on the root stacking context (which is not created by StackingContextHelper). Since we want a zero origin (as explained above) and the size is never used, we can just pass a zero rect to the WR stacking context from StackingContextHelper. In terms of the actual transform matrix, this patch now passes the full unmodified transform from nsDisplayTransform into WR. This transform gets applied onto the contents of the nsDisplayTransform. The contents' coordinate system is relative to the frame that generated the nsDisplayTransform. Again this maps directly to WR, where the transform on the stacking context gets applied to the contents of the stacking context; the contents' coordinates are relative to the stacking context. MozReview-Commit-ID: 7YcFk9QTX3B
0566b5df31c04769737a0f0d42441ab56262a0d9: Bug 1400034 - Back out changes that introduce scaling complexity to StackingContextHelper. r?ethlin,pchang draft
Kartikaya Gupta <kgupta@mozilla.com> - Mon, 18 Sep 2017 13:20:33 -0400 - rev 666362
Push 80384 by kgupta@mozilla.com at Mon, 18 Sep 2017 17:20:57 +0000
Bug 1400034 - Back out changes that introduce scaling complexity to StackingContextHelper. r?ethlin,pchang This backs out bug 1399050, bug 1394308 (2 patches), and bug 1391499. I believe these patches sent us down a path that would make the code increasingly more complex, when in fact we can do a more "direct" translation from the gecko display list to the WR display list and make things a lot simpler and more correct. MozReview-Commit-ID: 5gn4UGhO7t2
2893734f0f393a421fbdd7e7740c4cecb8f20055: Bug 1400034 - Turn on layers-free for transform/ and transform-3d/ reftests. r?ethlin,pchang draft
Kartikaya Gupta <kgupta@mozilla.com> - Sun, 17 Sep 2017 10:37:43 -0400 - rev 666068
Push 80263 by kgupta@mozilla.com at Sun, 17 Sep 2017 14:38:05 +0000
Bug 1400034 - Turn on layers-free for transform/ and transform-3d/ reftests. r?ethlin,pchang MozReview-Commit-ID: Ae80DrMwg1X
71df87f7ec982c103a0f98fe5a0ab465c583f4de: Bug 1400034 - Do a more direct translation of transforms from Gecko to WR in layers-free mode. r?ethlin,pchang draft
Kartikaya Gupta <kgupta@mozilla.com> - Sun, 17 Sep 2017 10:37:43 -0400 - rev 666067
Push 80263 by kgupta@mozilla.com at Sun, 17 Sep 2017 14:38:05 +0000
Bug 1400034 - Do a more direct translation of transforms from Gecko to WR in layers-free mode. r?ethlin,pchang In layers-free mode the gecko display list and coordinate system is very similar to what WR is expecting. Instead of having each StackingContextHelper shift the origin of the coordinate system, we can leave it in one spot and just pass everything relative to that. The semantics of the Gecko display list already matches this; the exception is that nsDisplayTransform items are also considered reference frames, and anything inside them is relative to the nsDisplayTransform. On the WR side this is also the case, because stacking contexts with a transform are implicitly turned into reference frames. Additionally, the size of the bounds passed to the WR stacking context is never actually used, except on the root stacking context (which is not created by StackingContextHelper). Since we want a zero origin (as explained above) and the size is never used, we can just pass a zero rect to the WR stacking context from StackingContextHelper. In terms of the actual transform matrix, this patch now passes the full unmodified transform from nsDisplayTransform into WR. This transform gets applied onto the contents of the nsDisplayTransform. The contents' coordinate system is relative to the frame that generated the nsDisplayTransform. Again this maps directly to WR, where the transform on the stacking context gets applied to the contents of the stacking context; the contents' coordinates are relative to the stacking context. MozReview-Commit-ID: 9hdDxdKXPPi
ed36b1d813bc06cd28dcf811a406991dc89c7ca5: Bug 1400034 - Back out changes that introduce scaling complexity to StackingContextHelper. r?ethlin,pchang draft
Kartikaya Gupta <kgupta@mozilla.com> - Sun, 17 Sep 2017 10:37:42 -0400 - rev 666066
Push 80263 by kgupta@mozilla.com at Sun, 17 Sep 2017 14:38:05 +0000
Bug 1400034 - Back out changes that introduce scaling complexity to StackingContextHelper. r?ethlin,pchang This backs out bug 1399050, bug 1394308 (2 patches), and bug 1391499. I believe these patches sent us down a path that would make the code increasingly more complex, when in fact we can do a more "direct" translation from the gecko display list to the WR display list and make things a lot simpler and more correct. MozReview-Commit-ID: ZXXkI9DXiY
66510c5e8690f2d45f3f17a8cdfffaf715d5cefa: Bug 1400034 - Turn on layers-free for transform/ and transform-3d/ reftests. r?ethlin,pchang draft
Kartikaya Gupta <kgupta@mozilla.com> - Fri, 15 Sep 2017 16:44:49 -0400 - rev 665674
Push 80145 by kgupta@mozilla.com at Fri, 15 Sep 2017 20:45:37 +0000
Bug 1400034 - Turn on layers-free for transform/ and transform-3d/ reftests. r?ethlin,pchang MozReview-Commit-ID: LvU3kT4rJCK
6cd954f4d1a96fb2aedff39e047d318934f951a0: Bug 1400034 - Do a more direct translation of transforms from Gecko to WR in layers-free mode. r?ethlin,pchang draft
Kartikaya Gupta <kgupta@mozilla.com> - Fri, 15 Sep 2017 16:30:21 -0400 - rev 665668
Push 80139 by kgupta@mozilla.com at Fri, 15 Sep 2017 20:30:43 +0000
Bug 1400034 - Do a more direct translation of transforms from Gecko to WR in layers-free mode. r?ethlin,pchang In layers-free mode the gecko display list and coordinate system is very similar to what WR is expecting. Instead of having each StackingContextHelper shift the origin of the coordinate system, we can leave it in one spot and just pass everything relative to that. The semantics of the Gecko display list already matches this; the exception is that nsDisplayTransform items are also considered reference frames, and anything inside them is relative to the nsDisplayTransform. On the WR side this is also the case, because stacking contexts with a transform are implicitly turned into reference frames. Additionally, the size of the bounds passed to the WR stacking context is never actually used, except on the root stacking context (which is not created by StackingContextHelper). Since we want a zero origin (as explained above) and the size is never used, we can just pass a zero rect to the WR stacking context from StackingContextHelper. In terms of the actual transform matrix, this patch now passes the full unmodified transform from nsDisplayTransform into WR. This transform gets applied onto the contents of the nsDisplayTransform. The contents' coordinate system is relative to the frame that generated the nsDisplayTransform. Again this maps directly to WR, where the transform on the stacking context gets applied to the contents of the stacking context; the contents' coordinates are relative to the stacking context. MozReview-Commit-ID: BQLfbKohIIm
e4ef594276e158c4daf3d66aceade29f1e59e952: Bug 1400034 - Back out changes that introduce scaling complexity to StackingContextHelper. r?ethlin,pchang draft
Kartikaya Gupta <kgupta@mozilla.com> - Fri, 15 Sep 2017 16:30:18 -0400 - rev 665667
Push 80139 by kgupta@mozilla.com at Fri, 15 Sep 2017 20:30:43 +0000
Bug 1400034 - Back out changes that introduce scaling complexity to StackingContextHelper. r?ethlin,pchang This backs out bug 1399050, bug 1394308 (2 patches), and bug 1391499. I believe these patches sent us down a path that would make the code increasingly more complex, when in fact we can do a more "direct" translation from the gecko display list to the WR display list and make things a lot simpler and more correct. MozReview-Commit-ID: 4jJgY8Xe6xe
dfade36563b41b049d679feb83a4ae6711180f04: Bug 1391841: Clip fallback display items using WebRender clips instead of doing the clip internally. r=ethlin
Jeff Muizelaar <jmuizelaar@mozilla.com> - Mon, 28 Aug 2017 10:25:00 -0400 - rev 654328
Push 76546 by maglione.k@gmail.com at Mon, 28 Aug 2017 16:22:40 +0000
Bug 1391841: Clip fallback display items using WebRender clips instead of doing the clip internally. r=ethlin This gives a huge performance improvement when scrolling mozilla.org. It's only used when we have blob images which now support tiling.
2ceb5ec58738a4044275fdd5d8caeb40ddbf8888: Bug 1390804 - When pushing a mask clip, don't record it in DisplayListBuilder's clip stack. r=ethlin
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 17 Aug 2017 13:54:25 -0400 - rev 649007
Push 74933 by bmo:boris.chiou@gmail.com at Fri, 18 Aug 2017 14:20:05 +0000
Bug 1390804 - When pushing a mask clip, don't record it in DisplayListBuilder's clip stack. r=ethlin Recording mask clips in the clip stack changes the value of TopmostClipId() which confuses the code in ScrollingLayersHelper. The mask clip can be thought of as an "out-of-band" clip that ScrollingLayersHelper doesn't need to know about. This patch adds a mechanism for pushing such "out-of-band" clips without touching the clip stack. MozReview-Commit-ID: 8Zeqtigk0cj
662b04e85be83f0dd9d2f1940daf561815e44f39: Bug 1390804 - When pushing a mask clip, don't record it in DisplayListBuilder's clip stack. r?ethlin draft
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 17 Aug 2017 13:54:25 -0400 - rev 648385
Push 74741 by kgupta@mozilla.com at Thu, 17 Aug 2017 17:54:56 +0000
Bug 1390804 - When pushing a mask clip, don't record it in DisplayListBuilder's clip stack. r?ethlin Recording mask clips in the clip stack changes the value of TopmostClipId() which confuses the code in ScrollingLayersHelper. The mask clip can be thought of as an "out-of-band" clip that ScrollingLayersHelper doesn't need to know about. This patch adds a mechanism for pushing such "out-of-band" clips without touching the clip stack. MozReview-Commit-ID: 8Zeqtigk0cj
bebab4283bed00d13ffa71729c0f60eb60c20ada: Bug 1386747 - Put the scroll thumb's animation id in the scroll data for APZ. r=ethlin
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 03 Aug 2017 15:32:01 -0400 - rev 620702
Push 72131 by bmo:ttromey@mozilla.com at Thu, 03 Aug 2017 20:16:41 +0000
Bug 1386747 - Put the scroll thumb's animation id in the scroll data for APZ. r=ethlin MozReview-Commit-ID: fELBQVHky6
1eb81f0f0e50850fa1c43cbbd37791e5d3784677: Bug 1386747 - Ensure that scroll thumb display items generate animation IDs. r=ethlin
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 03 Aug 2017 15:31:50 -0400 - rev 620701
Push 72131 by bmo:ttromey@mozilla.com at Thu, 03 Aug 2017 20:16:41 +0000
Bug 1386747 - Ensure that scroll thumb display items generate animation IDs. r=ethlin We need to create a WebRenderAnimationData item in order to preserve the animation id on the frame - this allows to re-use the same animation id over multiple display list building phases. MozReview-Commit-ID: 5Uj5sv6FUgt
d4d95cd1fdff0d5bbfa12882d295246744ba627d: Bug 1384000 - Call TriggerPendingAnimations in layers-free mode. r=ethlin,kats
Morris Tseng <mtseng@mozilla.com> - Thu, 03 Aug 2017 11:25:07 +0800 - rev 620200
Push 71964 by hchang@mozilla.com at Thu, 03 Aug 2017 08:20:34 +0000
Bug 1384000 - Call TriggerPendingAnimations in layers-free mode. r=ethlin,kats MozReview-Commit-ID: 6Jae5rfQ8k2
4ee1f374805f0465739223e2210c1c92f9d6c90b: Bug 1386747 - Put the scroll thumb's animation id in the scroll data for APZ. r?ethlin draft
Kartikaya Gupta <kgupta@mozilla.com> - Wed, 02 Aug 2017 13:45:50 -0400 - rev 619836
Push 71839 by kgupta@mozilla.com at Wed, 02 Aug 2017 17:50:44 +0000
Bug 1386747 - Put the scroll thumb's animation id in the scroll data for APZ. r?ethlin MozReview-Commit-ID: AXqXjU8oycv
45c403dbcb702bbd219b3aa03724e1661ba6ef92: Bug 1386747 - Ensure that scroll thumb display items generate animation IDs. r?ethlin draft
Kartikaya Gupta <kgupta@mozilla.com> - Wed, 02 Aug 2017 13:45:47 -0400 - rev 619835
Push 71839 by kgupta@mozilla.com at Wed, 02 Aug 2017 17:50:44 +0000
Bug 1386747 - Ensure that scroll thumb display items generate animation IDs. r?ethlin We need to create a WebRenderAnimationData item in order to preserve the animation id on the frame - this allows to re-use the same animation id over multiple display list building phases. MozReview-Commit-ID: 8JcChwm1IAV
b6a15a11a52958b32e84e885b257c4ec33ea9f92: Bug 1385070 - Remove the WebRenderOMTAEnabled pref. r=ethlin
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 27 Jul 2017 16:11:17 -0400 - rev 617443
Push 71048 by bmo:emilio+bugs@crisal.io at Fri, 28 Jul 2017 12:58:45 +0000
Bug 1385070 - Remove the WebRenderOMTAEnabled pref. r=ethlin MozReview-Commit-ID: CWdrpzorNxq