New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 615518 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Oct 2017
Cc:
█ fsam...@chromium.org
rjkroege@chromium.org
sadrul@chromium.org
sky@chromium.org
mustash-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

Need something like CompositorResizeLock for Mus

Project Member Reported by ben@chromium.org, May 27 2016 
content/browser/renderer_host/render_widget_host_view_aura uses this thing called CompositorResizeLock to ask the system to stop dispatching pointer moves until the renderer has produced a frame at the expected size.

This is done to allow for smoother resizing of the content area as the enclosing window is resized.

We will need something like this in Mus for mus+ash.
(Note this problem is solved differently on MacOS, and not solved at all on Windows/Linux/Android, though people are thinking about it. If we want to use Mus elsewhere we'll have to understand how to apply those solutions as well).

Comment 1 by ben@chromium.org, May 27 2016

Cc: sky@chromium.org
Labels: -Pri-2 Pri-1
In fact, resizing is quite janky atm.

Two different cases of differing complexity:
- open any window in mash, e.g. task viewer, & resize. Note the content struggles to keep up with the window frame.
- open the mash:browser, load a page & resize. Note that both the browser UI & the content area struggle to keep up with the window frame.

The first case can likely be solved simply using a mechanism similar to CompositorResizeLock. The second one is more interesting to think about. The crux of the problem is deferring taking further action (resizes, pointer moves) until all the affected windows' surfaces are the correct size for the last one.

It seems like this could all be done in Mus, if Mus were to know for some tree of windows which were going to resize, & what the intended sizes were, & then pause events until new surfaces @ the correct sizes had been submitted.

Comment 2 by sadrul@chromium.org, May 27 2016 

One interesting proposal is to use a declarative layout-manager ( issue 568654 ) for this.

Comment 3 by ben@chromium.org, May 27 2016 

We need to think carefully about this. I think it's fair to say that computing the bounds of a window will always require its parent to be consulted. At least this is true for the web - if you hope to have OOPIF use this, you're going to have to allow Blink (& maybe script) to resize the subframes. & we're going to need to smoothly resize these to the best of our ability.

Comment 4 by cbiesin...@chromium.org, Jul 25 2016

Components: MUS

Comment 5 by fsam...@chromium.org, Aug 17 2016 

Yea, I think we need to let the compositor lead ahead of the window server.

Comment 6 by fsam...@chromium.org, Aug 17 2016 

We need to worry about lifetime management here and about making sure the subwindow doesn't resize faster than the parent. The lifetime management issues are similar for animations FWIW.

Comment 7 by rjkroege@chromium.org, Oct 4 2016

Components: Internals>MUS
Labels: Proj-Mustash
Project Member

Comment 8 by sheriffbot@chromium.org, Oct 5 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 9 by rjkroege@chromium.org, Oct 16 2017

Status: WontFix (was: Untriaged)
surface sync and its various extension subsume this in other bugs.

Comment 10 by lafo...@chromium.org, Feb 26 2018

Components: -Internals>MUS Internals>Services>WindowService

Comment 11 by lafo...@chromium.org, Feb 26 2018

Components: -MUS
►

Sign in to add a comment