New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 849365 link

Starred by 1 user

Issue metadata

Status: Available
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Support ChildLocalSurfaceIdAllocator in ws2

Project Member Reported by sky@chromium.org, Jun 4 2018

Issue description

ws2 only supports ParentLocalSurfaceIdAllocator. We may have cases where it would be nice to support ChildLocalSurfaceIdAllocator (browser resizes most likely).
 
Owner: jonr...@chromium.org
Status: Assigned (was: Untriaged)
Labels: Proj-Mash-SingleProcess
Jon, would you happen to know if this is necessary for single-process-mash? What are the symptoms if we didn't do this?
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.
Labels: -Proj-Mash-SingleProcess Proj-Mash-MultiProcess
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!
Cc: jonr...@chromium.org
Owner: sky@chromium.org
Status: Available (was: Assigned)
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
Cc: samans@chromium.org
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.
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