Verify exo subsurface synchronization |
||||
Issue descriptionWith CL https://codereview.chromium.org/2868473002, exo will only allocate new surface, when surface's size is changed. It may break exo subsurface synchronization. We need create a test to verify it. If it does break, fix it.
,
May 31 2017
We might need some form of pixel test to verify this in a reliable way.
,
May 31 2017
I created a wayland client to verify subsurface features, and didn't find any issue. See[1] [1]https://chromium-review.googlesource.com/c/518983/
,
May 31 2017
If each subsurface has a CompositorFrameSink and they're all submitting CompositorFrames asynchronously then there's no guarantee that a display frame isn't generated at some point within your animation loop. In that case, you'll get an inconsistent frame.
,
May 31 2017
I think for CASH, it shouldn't have this problem, because they all in the same thread, and SubmitCompositorFrame() should be synchronized operations. For mus, it may happen with current Mus API, but I think we can find a way (for example all CFS share one message pipe in one process) to resolve it.
,
May 31 2017
Sharing a MessagePipe doesn't solve the problem either because the display compositor is on a separate thread (separate process) and so a display frame may be generated at any point in between calls to SubmitCompositorFrame.
,
May 31 2017
As discussed offline, I think we want each exo app to submit a single CompositorFrame. Each exo app is a WindowTreeHost. That should solve the synchronization issues, and allow us to avoid special casing in the window server or viz.
,
May 31 2017
,
Jun 20 2017
,
Sep 20 2017
We are using one frame sink for surface tree now, and it should not have any surface sync issue. |
||||
►
Sign in to add a comment |
||||
Comment 1 by penghuang@chromium.org
, May 31 2017