Mac: Resize has become less smooth as of M46 |
|||||||||
Issue descriptionMac, M46+ What steps will reproduce the problem? (1) Resize vigorously (using the lower-left corner, ideally with scrollbars visible) (2) Notice that it is not particularly smooth See attached videos. The issue is that we don't get synchronization of the updates from the remote CALayers in the GPU process. This can be fixed by moving the CALayer tree to the browser process, or by creating a new remote CALayer at resize (see prototype at https://codereview.chromium.org/2042123002/).
,
Jun 7 2016
Issue 617008 has been merged into this issue.
,
Jul 22 2016
Any progress on this? This bug hurts the user experience.
,
Mar 22 2017
This is awesome and a half, thanks for digging in to this.
,
Mar 23 2017
Sure thing. I'm deferring to you and erikchen@ on next steps (e.g. what we still need to investigate, whether there's a better home for this fix, if there's a known way to get called back during the transaction without using private APIs).
,
Mar 25 2017
Quick note — I think I discovered why this works. While in that post commit handler, the entire area of the screen taken up by the window is frozen. Attached is a screen recording where I added a super long delay on the renderer side at that point to demo. That doesn't disqualify this solution, just suggests that most of the work should probably happen before the commit, like it does now, and only the final "go ahead and swap/paint/whatever" should be inside.
,
May 3 2017
,
May 3 2017
Issue 705278 has been merged into this issue.
,
May 3 2017
Marking as available PE bug
,
Jul 21 2017
Issue 746905 has been merged into this issue.
,
Aug 17 2017
,
Sep 25 2017
,
Nov 30 2017
ccameron@ et. al: I just wanted to share a quick PoC of a working fix that's minimally invasive: https://chromium-review.googlesource.com/c/chromium/src/+/798774 Think there's a more elegant way to thread it through (and only do it during a resize, probably)?
,
Dec 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d2f3e5933b3c9dab1b0f0fc3c5f1f3451cdffc4d commit d2f3e5933b3c9dab1b0f0fc3c5f1f3451cdffc4d Author: Sidney San Martín <sdy@chromium.org> Date: Thu Dec 14 02:00:28 2017 [Mac] Make synchronized content resize/repaint visually atomic. NSDisableScreenUpdates() is advertised for making visually atomic changes that affect multiple windows, but it it's also effective when multiple processes have layers in the same window. macOS uses it to synchronize resizing of out-of-process views like NSOpenPanel. Leaving screen updates disabled for too long can create funky visual artifacts within and behind Chrome windows if left on for too long. This waits to flip it until a frame has been produced of the new size, and it's only on during the (very brief) compositor swap. Bug: 617824 , 741478 Change-Id: Id6ddfb8848342d6e4b148207a3f76125774081d6 Reviewed-on: https://chromium-review.googlesource.com/798774 Commit-Queue: Sidney San Martín <sdy@chromium.org> Reviewed-by: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#523982} [modify] https://crrev.com/d2f3e5933b3c9dab1b0f0fc3c5f1f3451cdffc4d/content/browser/renderer_host/render_widget_host_view_mac.h [modify] https://crrev.com/d2f3e5933b3c9dab1b0f0fc3c5f1f3451cdffc4d/content/browser/renderer_host/render_widget_host_view_mac.mm
,
Mar 5 2018
Marking fixed but not verified. sandeepkumars@: Is it still that janky for you? That looks super bad.
,
Mar 5 2018
For anyone following along: this fix is in M65.
,
Mar 8 2018
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by ccameron@chromium.org
, Jun 7 2016