There is already code which does this in content/renderer/render_widget.cc:

  actual.bytes_limit_when_visible = 512 * 1024 * 1024;
  actual.priority_cutoff_when_visible =
      gpu::MemoryAllocation::CUTOFF_ALLOW_NICE_TO_HAVE;

  // For large monitors (4k), double the tile memory to avoid frequent out of
  // memory problems. 4k could mean a screen width of anywhere from 3840 to 4096
  // (see https://en.wikipedia.org/wiki/4K_resolution). We use 3500 as a proxy
  // for "large enough".
  static const int kLargeDisplayThreshold = 3500;
  int display_width =
      std::round(initial_screen_size.width() * initial_device_scale_factor);
  if (display_width >= kLargeDisplayThreshold)
    actual.bytes_limit_when_visible *= 2;

Maybe we just need to lower the threshold if our hi res (but not quite 4K) devices are running out?


Note that in ui/compositor/compositor.cc:

  settings.memory_policy.bytes_limit_when_visible = 512 * 1024 * 1024;
  settings.memory_policy.priority_cutoff_when_visible =
      gpu::MemoryAllocation::CUTOFF_ALLOW_NICE_TO_HAVE;

There is no similar logic to account for high resolutions. It might make sense to keep these in sync. Antoine, what do you think?

Sure, raising the limit is possible, but why does the UI need this much memory? 4k is only like 32MB or so for a screen worth of tiles.

This is to mitigate the issue like this:

https://bugs.chromium.org/p/chromium/issues/detail?id=905388#c7

This gets worse in tablet mode because all windows are maximzied.

We're working on improving memory usage in ovewview mode (better rounded corners impl,
reduce forebround blur quality, and so forth), and we'll revisit this if we can reduce
it again.