GitLab

This diverged from original implementation, which did not use such 250ms delay,
and is potentially causing issues when xrandr and scale factor change events
come in a short interval, as observed in crbug.com/1019344.

Rationale:

With delayed update, events are coalesced thus leading to issues when
DisplayObserver is waiting only for display metrics changes, e.g: scale factor
changes. This is what RenderWidgetHostViewAura does, in order to react to
system's scale factor changes and sync with the compositor, etc.

In this specific issue, the delayed display list update behaves as follows:

Assuming display list initially has a single display (Display 1). XRandR/Gtk
events start coming:

1. Display 2 added
2. Display 1 removed
3. Display 2 metrics changed (scale factor)

Then they are coalesced into (and delivered through DisplayObserver interface):

1. Display 1 removed
2. Display 2 added

So, RenderWidgetHostViewAura::OnDisplayMetricsChanged() is never called and it
gets out of sync with the compositor.

Bug: 1019344
Change-Id: Ic6a7b1264b5656d36a0b25fd7e3bc07ab419568a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1930853
Commit-Queue: Nick Yamane <nickdiego@igalia.com>
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#718325}