+fsamuel: From a trace, the child frame isn't producing new frames. So looks like parent is just embedding the same surface during pinch zoom? Is that intentional (since using surface sync is presumably going to super janky)?

Deleted: trace_si_pinch_zoom.json.gz 1.0 MB

trace_si_pinch_zoom.json.gz 1.0 MB Download

+piman@, gklassen@, jonross@:

We have known about this issue for a long time. The problem is we don't update the raster scale as we pinch-to-zoom.

Jon Ross (jonross@) has proposed a scheme to make this possible and reasonably efficient (direct client to client visual properties sync). https://docs.google.com/document/d/1rHi5RmXEZjKb7AUve968xbpJjKCxNMJtMHKdWyxPPpA/edit

With that said, we may not currently have the bandwidth to get this done soon. We are inching towards it.

oops, readding myself.

wjmaclean@ has also been planning to fix this as part of pinch zoom for a while (in  issue 654917 , I think).  James and Jon, are you aware of each others' work?  :)

Maybe easier first step, can we update everything after pinch zoom is done, ie after user lifts fingers off the screen? That doesn't appear to work today either.

(Ignore if the full solution is close)

That seems like a reasonable first step...the full solution can happen in parallel largely.

Maybe if we stick the raster scale on VisualProperties, then the rest can happen through Jon's refactor.

I had not heard of wjmaclean's plans in this area. I'll sync up with them

Re C#5, just updating at the end of a pinch zoom won't help with things as they are at present, since OOPIFs don't know what the page scale factor is, so they would just re-draw at the same raster scale.

I'm happy to pass this (654917) over to Jon if he has a plan to sync the raster scale over to the OOPIFs via viz properties.

I guess there are two separable components here:

Teaching cc about raster scale from LayerTreeHost via VisualProperties and making a direct channel to propagate VisualProperties.

I think we (viz) might want to own the direct channel part leaving the raster scale plumbing up to wjmaclean@. What do you all think?

Re C#9, I'm not sure I'm clear on what the two parts are.

Assuming that "making a direct channel" is basically a direct communication between LayerTreeHost in different renderers, and that raster_scale presumably would travel across that channel, I'm not sure what other plumbing remains?

I think in the general case, all "VisualProperties" need to be plumbed alongside one another to avoid races. In particular, if we want to provide any kind of synchronization guarantees (even soft guarantees), we need to allocate new LocalSurfaceIds along with plumbing raster scale. There's a bunch of pre-work there in order to avoid races with other visual properties such as visibility that are not currently propagated via VisualProperties.

See jonross@'s doc above for some of the details.