Support ChildLocalSurfaceIdAllocator in ws2 |
|||||
Issue descriptionws2 only supports ParentLocalSurfaceIdAllocator. We may have cases where it would be nice to support ChildLocalSurfaceIdAllocator (browser resizes most likely).
,
Aug 27
,
Oct 3
Jon, would you happen to know if this is necessary for single-process-mash? What are the symptoms if we didn't do this?
,
Oct 3
I don't believe that we need this for single-process-mash. With ws2 being the Embedder, it should only be using ParentLocalSurfaceIdAllocator. Each embedded-client would then use ChildLocalSurfaceIdAllocator. For the case in #1 Ash doing an interactive resize of the browser would set the LSI as needed, and send that to the browser. Whereas if the browser wanted to resize, it can allocate an LSI and send it to the embedder. ws2 already supports a child providing an LSI on resize. So we seem to have that covered. I'm slightly concerned about ws::WindowTree::SetWindowBounds setting an empty LSI, which doesn't seem to get updated. But that might be worth tracking in its own issue.
,
Oct 3
ws::WindowTree::SetWindowBounds() should update the LSI of the root. Code for that is here: https://chromium.googlesource.com/chromium/src/+/master/services/ws/window_tree.cc#1152 Maybe you are referring to something else Jon? I'm going to retarget this to multi-process mash. If I'm wrong about that, please retarget. Jon, if you do know of bugs, please file and target appropriately. Thanks!
,
Jan 4
Passing onto sky@ to assign appropriately for multi-process mash. From offline investigation/discussion: The client (more specifically, WindowPortMus) should allocate ids using ChildLocalSurfaceIdAllocator. Use case is the bounds negotiation. So that after WindowTreeClient::OnWindowsBoundsChanged is called. Followed by the server's response: WindowTreeClient::OnChangeCompleted(false) we are then able to update the WindowPortMus' LocalSurfaceId, via ChildLocalSurfaceIdAllocator::UpdateFromParent, rather than using the current ParentLocalSurfaceIdAllocator::Reset
,
Jan 4
One thing I'd like to add is revert logic can cause surface invariants violations. I think we should allocate a new LocalSurfaceId on revert instead.
,
Jan 4
Yeah, that is the goal behind switching the allocator type. Currently the reset process occurs before the new LSId is ever embedded. Which is how surface invariants violations are avoided. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by fsam...@chromium.org
, Aug 27Status: Assigned (was: Untriaged)