mirror of
https://github.com/mozilla/gecko-dev.git
synced 2025-03-03 15:26:07 +00:00
a57976fc90
When the scale of the parent transform is increasing the parent scale will be much larger than the scale of the parent transform. The bug in the testcase happens because there are two nested transforms. The outer is animating in scale between 0 and 1. So the choosen mScale for the parent is 1 and the scale of the transform at any instantaneous point is usually smaller, say 0.2. The inner transform is just a flip and is not animated. We combine that parent transform with our local flip transform and get a transform with a scale of 0.2 and use that as our mScale. However this ignores the animating aspect of the parent transform and the fact we choose an mScale of 1 for the parent. To fix this we bring how we use ChooseScale with webrender more into alignment with how we used ChooseScale with non-wr/FrameLayerBuilder. https://searchfox.org/mozilla-esr91/rev/f3f439e007bdd4b5b1c2ba05ca706b68563413b2/layout/painting/FrameLayerBuilder.cpp#6047 The old code was structured a little differently which obscured this difference. The old code had ChooseScale (the code shared by webrender and FrameLayerBuilder) and a wrapper function ChooseScaleAndSetTransform which only FrameLayerBuilder used. The old code passed the local transform to ChooseScaleAndSetTransform, and then ChooseScaleAndSetTransform combined it with the parent scale and then passed that transform to ChooseScale. Whereas webrender passed the combined transform to ChooseScale. This would produce the same results except if the scale was animating. This mimics how we compute the scale in HasAnimationsForCompositor branch above, where we compute a scale for the local transform and then combine that with the parent scale. See also bug 1569215 where we first started passing the parent scale into ChooseScale so that the HasAnimationsForCompositor would choose the correct scale. Differential Revision: https://phabricator.services.mozilla.com/D178996