Server-driven window management in ARC |
|||
Issue descriptionFor ARC, Exosphere does not synchronize window state changes (e.g. normal to maximized) with the client. In addition, the client controls window dragging/resizing, and the server-side window bounds are updated asynchronously. There are several consequences: 1) Visual artifacts. For instance, when a window becomes maximized or full screen, the server does not wait until the client produces content for the new size before switching to the new window state, so the old content may briefly appear in the new window state. 2) Inconsistent state. For example, if immersive or overview mode is entered while dragging, the server may incorrectly apply geometry updates that the client sent before aborting the drag. Likewise, reverting a drag (e.g. after unplugging a display) requires synchronization to avoid races resulting in inconsistent state. 3) Shallow Ash integration, preventing effects like cross-fading during maximization, and snapping to Chrome windows during dragging/resizing. Also, client-side resizing is inconsistent with Chrome in look (e.g. no resize shadows) and feel (e.g. no leeway outside window frame for grabbing edges). The solution is to implement the "configure" protocol for window state and geometry, and give control over window operations (e.g. initiating/aborting a drag) to the server. Note that this protocol is already used to apply geometry updates using the correct coordinate system during display reconfiguration.
,
Apr 4 2017
,
Apr 4 2017
Note that this is more important when we implement more advance Window management such as split screen, or PIP etc.
,
Apr 4 2017
mtomasz: Yes, as soon as multi-display support lands. Some pieces of the "configure" protocol have already landed as part of that work, i.e. to synchronize coordinate system changes when displays are added/removed/moved.
,
Apr 5 2017
What's the target milestone? I was wondering if we need it all to make the window animations work for maximize/restore.
,
Apr 6 2017
Probably M60. The first step is switching to the "configure" protocol for window state changes. Window animations can then be implemented independently from the "moving" and "resizing" window states, which are comparatively more involved.
,
Apr 10 2017
I'd like to increase the priority on this feature if possible. Using ARC++ I find the window state transitions to be quite janky. Any chance we can attempt to pull this in for 59?
,
Jun 27 2017
Any update?
,
Jun 27 2017
Dominik, do you plan to work on it for 61? I'm happy to help. I'm trying to wrap my head around the idea of the configure protocol. It's exo -> arc direction, so not sure how it would help us synchronize the frames. IIUC we need something opposite. We need to know that a frame which we receive from arc is already for the new window state. Then we can start the crossfade animation. Am I missing something?
,
Jun 27 2017
The plain is that we'll work on hybrid approach first. There may still want to do this (move to full server side), but there are things we need to solve first (it'll most likely break CTS tests, for example)
,
Jun 27 2017
@#9, each configure event comes with the current state of the shell surface and a serial. when submitting a frame back to the compositor (as part of an atomic surface::commit()) we can include a configure_ack with the serial of what state the contents of this commit represents. chrome doesn't handle this perfectly yet but could relatively easily be made to wait on the configure ack before starting a state transition animation.
,
May 21 2018
|
|||
►
Sign in to add a comment |
|||
Comment 1 by mtomasz@chromium.org
, Apr 4 2017