Mus: Refactor device emulation plumbing |
|||||||||
Issue descriptionThere is a bunch of device emulation code that plumbs sizing information that doesn't correspond to window size changes (from Mus' perspective). On the renderer side, this is: RenderWidgetScreenMetricsEmulator. https://cs.chromium.org/chromium/src/content/renderer/devtools/render_widget_screen_metrics_emulator.h?gsn=RenderWidgetScreenMetricsEmulator&l=1 On the browser side, this is EmulationHandler. https://cs.chromium.org/chromium/src/content/browser/devtools/protocol/emulation_handler.cc?type=cs&q=EnableDeviceEmulation&l=1 We need to figure out what we want to do with those in a Mus+Ash/Mushrome environment. Perhaps we can integration device emulation in the window server? Note that this also impacts compositing logic because it interacts with surface synchronization.
,
Apr 17 2017
,
Apr 18 2017
I am not sure about surface sync, but I don't think we need to do anything here for mushrome for screen/touch etc. emulation. The emulation happens between browser and renderer (and affects only browser), and should continue to work. For the longer term, the emulation should indeed live in the window server. Can we create a narrower-scoped bug for surface-sync for mushrome?
,
Apr 19 2017
,
Apr 20 2017
So the problem with surface sync is the surface ID needs to be allocated in the browser ID for the renderer and then passed along for resize. With screen metrics emulator, we are resizing the RenderWidget in the renderer without going through the browser process. This needs to change.
,
May 3 2017
,
May 23 2017
,
Jun 8 2017
,
Jun 13 2017
After some digging, it seems that we don't need to do anything here because Blink is producing a full sized frame so no resize is actually happening...I'm not sure why we're bundling device emulation along with resize..maybe we should refactor that code but this is not blocking viz or mushrome.
,
Jun 13 2017
,
Feb 26 2018
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by fsam...@chromium.org
, Apr 15 2017