Exo should submit CompositorFrames via the MojoCompositorFrameSink |
|||||||||||||||||
Issue descriptionCurrently exo directly holds a CompositorFrameSink (that implements the MojoCompositorFrameSink interface), but calls methods on that CompositorFrameSink directly. In an out-of-process display compositor, that will be an IPC call. Exo apps have a number of subsurfaces that all need to update atomically. This is blocked on surface synchronization.
,
Apr 17 2017
Note that this also has performance implications. We need to understand the impact this will have on ARC++ apps and we need to come up with mitigations as necessary. Obviously, the cost of shipping CompositorFrames to another process introduces overhead which may impact performance / battery life.
,
Apr 19 2017
,
May 3 2017
Assigning to penghuang@
,
May 3 2017
,
May 4 2017
,
May 10 2017
,
May 23 2017
,
Jun 1 2017
,
Jun 12 2017
,
Jun 13 2017
,
Jun 13 2017
,
Jun 14 2017
,
Jun 14 2017
,
Jun 20 2017
,
Jun 20 2017
I have a CL make this work. But it has performance regression we need figure how why the regression happens, if we can accept it. See issue 729028.
,
Sep 21 2017
Exo already submit frames through Mojo frame sink with mus and mash but not for cash. I think this issue is not a blocker for mushrome.
,
Aug 2
penghuang@ this is obsolete yes? At least in a Viz context? You should reopen if you disagree. |
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by fsam...@chromium.org
, Apr 12 2017