Experiment with IPC overhead of ui::Compositor's CompositorFrames |
|||||||||||||
Issue descriptionWe are now in a position to test the performance overhead of mojo IPC from ui::Compositor. We should fork DirectCompositorFrameSink and split the fork similar to exo's CompositorFrameSink and CompositorFrameSinkHolder or GpuCompositorFrameSink and WindowCompositorFrameSink. There should be a command line flag to use the mojo based CompositorFrameSink from ui::Compositor. We should run a Finch trial to see what impact, if any, this has on performance. We need to decide what the parameters are of the experiments we'd like to conduct: what trace events and UMA stats do we want to record?
,
Feb 21 2017
Sizes of CFs for top 10k websites: https://docs.google.com/spreadsheets/d/1Vene8b3ZWQ0PAhSOOIje6eB2BAt3xxcZhLuHz7tSl8Y/edit#gid=1913552190
,
Apr 17 2017
Assigning to kylechar@
,
Apr 19 2017
,
May 23 2017
,
Jun 5 2017
I'm unlikely to get to this anytime soon, marking as available.
,
Jun 12 2017
,
Jun 12 2017
,
Jun 13 2017
Is this bug mainly about changing from old IPC system to Mojo? Does CL https://codereview.chromium.org/2774373002 cover this?
,
Jun 13 2017
This bug is about IPC vs no IPC, as opposed to Mojo vs Chrome IPC. Currently ui::Compositor submits to an in-process display compositor with no IPC overhead. We would like to know the effect on performance if it has to submit to another process.
,
Jun 13 2017
,
Aug 9 2017
,
Nov 21 2017
,
Aug 14
Bug label scrub.
,
Aug 15
Cleaning up old Proj-Mustash labels. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by fsam...@chromium.org
, Feb 21 2017