Ensure potentially expensive operations don't break APZ

[nical]

Followup from #1370 to discuss architecture changes we want to make in order to move expensive operations out of the critical path.

[glennw]

Crazy idea / question:

Could we ship the clip-scroll tree along with each frame we send to the compositor thread? I'm not sure if it's feasible or how costly it would be.

But if it were feasible, then the APZ could actually be done on the compositor thread - just by updating transforms in the clip-scroll tree, and then patching the list of matrices that get uploaded for a frame.

In such a scenario, the render backend would no longer have any involvement in APZ - the render backend could happily be producing a new frame, while the compositor can tweak the clip-scroll tree and list of transforms. This is hand-wavy, but I'd assume we could also extract information from the clip-scroll tree that would allow the compositor to know where to draw checkerboard regions.

Potentially, this could also have an effect on how hit-testing works (if we do it in WR, allowing it to be done on the compositor thread), although that's even more speculative than the above.

If that worked, it seems like it might simplify the APZ implementation a lot.

Does that make any sense @mrobinson @kvark @nical @staktrace @jrmuizel ?

[staktrace]

I don't have a good mental model of some of this, so please correct me if what I say makes no sense...

Are you thinking of duplicating the clip-scroll tree, or just sharing it across the two threads? If we end up with two copies, and we only update the one on the compositor thread with APZ, then we would have to use that updated one for hit-testing (assuming we do it in WR at all). Updating both copies doesn't make sense since we'd have to block on the render backend thread to do the update which negates the benefit of this approach.

[staktrace]

I filed #1575 for exposing a hit-test API.

[gw3583]

I think this is all in place now.