Move parent LocalSurfaceId allocation to RenderWidgetHostImpl::SynchronizeVisualProperties |
|||||
Issue descriptionIn RenderFrameProxy::SynchronizeVisualProperties we allocate a new LocalSurfaceId if one of the visual properties has changed. In RenderWidgetHostImpl::SynchronizeVisualProperties we grab the visual properties AND the LocalSurfaceId from the RenderWidgetHostView and hope the invariant "Change In Properties => new LocalSurfaceId" holds. This seems bad. We should just allocate LocalSurfaceIds in RenderWidgetHostImpl::SynchronizeVisualProperties and move the LocalSurfaceId OUT OF VisualProperties struct. The current blocker for this is Mus: aura::Window likes to do its own LocalSurfaceId allocations in order to propagate to children. Maybe we should move LocalSurfaceIds entirely out of aura and Mus?
,
May 17 2018
Scott: I'd like to move LocalSurfaceIds entirely out of aura::Window, Mus and so on. I think it should be up to clients to manually update LocalSurfaceIds on layers or to update their LocalSurfaceIds from the parent. The window service doesn't need to know about LocalSurfaceId at all.
,
May 17 2018
I'm all for simpler. If this won't break anything, go for it.
,
May 24 2018
,
Aug 27
,
Aug 27
,
Aug 27
Sadrul pointed out that Exo will need to have LocalSurfaceId allocation code though because it currently relies on Aura to do the work for it.
,
Oct 1
Fady, is this needed for single-process-mash?
,
Nov 5
I'm assuming this isn't needed for single-process-mash. Jon and/or Fady, please add back single-process-mash if it is necessary. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by khushals...@chromium.org
, May 16 2018