Bug 1576923 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

The way this is handled for non-WebRender, is that the clip is "outside" the zoom (when rendering a layer, we apply its transform first, and then apply the clip to the result). I feel like it would make things more consistent if WebRender behaved similarly; not sure how feasible that is.

If we can't get the clip to be outside the zoom, then yes, scaling the clip asynchronously with the async zoom would make sense.

In terms of where to do that, a couple of starting points for investigation:

 * The place where APZ records the current async zoom transform for WebRender is [here](https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/gfx/layers/apz/src/APZCTreeManager.cpp#667).
 * The place where that information makes it to the Rust side of the WebRender API is [here](https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/gfx/webrender_bindings/src/bindings.rs#992). Note, by this point we may not be able to distinguish the async zoom from the other async transforms. We may need to modify the API to give the async zoom or special label, or something like that.

Presumably, we want to apply the async zoom to the clip "per frame" (since the async transforms can change per frame), somewhere after the async transforms are sampled, and somewhere before the clip is applied. I'm afraid I don't have more specific pointers for this part :/ Perhaps someone with more knowledge of the Rust side of WebRender can help us out here?
The way this is handled for non-WebRender, is that the clip is "outside" the zoom (when rendering a layer, we apply its transform first, and then apply the clip to the result). I feel like it would make things more consistent if WebRender behaved similarly; not sure how feasible that is.

If we can't get the clip to be outside the zoom, then yes, scaling the clip asynchronously with the async zoom would make sense.

In terms of where to do that, a couple of starting points for investigation:

 * The place where APZ records the current async zoom transform for WebRender is [here](https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/gfx/layers/apz/src/APZCTreeManager.cpp#667).
 * The place where that information makes it to the Rust side of the WebRender API is [here](https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/gfx/webrender_bindings/src/bindings.rs#992). Note, by this point we may not be able to distinguish the async zoom from the other async transforms. We may need to modify the API to give the async zoom a special label, or something like that.

Presumably, we want to apply the async zoom to the clip "per frame" (since the async transforms can change per frame), somewhere after the async transforms are sampled, and somewhere before the clip is applied. I'm afraid I don't have more specific pointers for this part :/ Perhaps someone with more knowledge of the Rust side of WebRender can help us out here?

Back to Bug 1576923 Comment 2