Hey danakj@ it looks like you originally worked on simplifying the cull regions into the SimpleEnclosedRegion, around the compositor-perf efforts.

Any ideas on how to improve this?  I assume complete regions had a lot of CPU overhead.

Yes I made some comments in the doc, but basically I think we just need to do culling in the Display compositor, then it will work across surfaces so we can cull quads from within tab contents.

There is some weird overdraw when a window is overlapped the whole window starts to overdraw. But that looks like it's no longer being treated as opaque as opposed to a culling issue - it happens everywhere on the lower-z-order window.

Complete regions were excessively CPU costly, and I don't think they will add much/anything here.

We could dupe this into 672929.. There's also the issue of why a window overdraws everything when you overlap it at all. I can't investigate more until I can use the overdraw tool really which reveman is working on landing.

We should probably reevaluate after 672929 to see that it is indeed okay, cuz maybe it won't be for whatever reason. So maybe it makes sense to leave this open.

Issues  672929  seems like would solve the 3rd issue (Windows don't appear to cull content quads in background windows) but it's not clear to me how it would solve the other two issues.

I think the double-overdraw issue could be solved if UI didn't produce quads for the background behind content.

Oh I didn't see the side by side window section, my bad. We could expand the occlusion region to two rects or something, as long as the math is simple. Here's some background reading on occlusion tracker being slow before:

https://bugs.chromium.org/p/chromium/issues/detail?id=163035
https://bugs.chromium.org/p/chromium/issues/detail?id=405663
https://bugs.chromium.org/p/chromium/issues/detail?id=124687
https://bugs.webkit.org/show_bug.cgi?id=81076

Is this side-by-side window case something that is affecting users? My understanding is majority of users work with maximized windows on laptops (and desktops).

CrOS folks, do we have data on window statistics?

I would imagine users have multiple windows open - e.g. CrOS file viewer open at the same time as the browser - and not not maximized 100% of the time.

^ The CrOS overview mode also puts all windows side by side.  At least overdraw has some upper bound when everything is non overlapping.

One tweak that might help, right now it favors keeping the old rect over a new rect in the computation. So you get occlusion from the first tab contents but not from any others. If we allowed later tab contents occlusion rects to replace the first we'd get each chrome window getting occluded by its own tab contents, while the wallpaper only occluded by the last window. That would reduce one level of overdraw on all windows. It would struggle with draw occlusion in the display compositor though, because then smaller rects would need to replace a larger rect, and we probably need to track 2 rects to accomplish that.

I don't know if we have any window statistics for CrOS but I'll look into it. Here are some reasons for why the assuming that windows are maximized might become a bad assumption.

- CrOS window snapping feature makes it easy to have two windows share the screen.
- Many Android apps do not make sense to run maximized.
- CrOS external monitor support is increasing.
  * Less likely that users have windows maximized on a large external monitor?
  * With unified desktop, all monitors are driven by one compositor instance so a maximized window on each monitor is really two windows side-by-side.
- UI effects such as overview mode and window switcher effectively place windows side-by-side

I wonder, what does this do for overview mode?

diff --git a/cc/base/simple_enclosed_region.cc b/cc/base/simple_enclosed_region.cc
index 50e905bb68c9..1db0ad68662a 100644
--- a/cc/base/simple_enclosed_region.cc
+++ b/cc/base/simple_enclosed_region.cc
@@ -18,6 +18,12 @@ static bool RectIsLargerArea(const gfx::Rect& a, const gfx::Rect b) {
   return a_area > b_area;
 }
 
+static bool RectIsLargerAreaThanHalf(const gfx::Rect& a, const gfx::Rect b) {
+  int64_t a_area = static_cast<int64_t>(a.width()) * a.height();
+  int64_t b_area = static_cast<int64_t>(b.width()) * b.height();
+  return a_area > b_area / 2;
+}
+
 SimpleEnclosedRegion::SimpleEnclosedRegion(const Region& region) {
   for (Region::Iterator it(region); it.has_rect(); it.next())
     Union(it.rect());
@@ -127,7 +133,7 @@ void SimpleEnclosedRegion::Union(const gfx::Rect& new_rect) {
 
   gfx::Rect adjusted_new_rect(
       new_left, new_top, new_right - new_left, new_bottom - new_top);
-  if (RectIsLargerArea(adjusted_new_rect, rect_))
+  if (RectIsLargerAreaThanHalf(adjusted_new_rect, rect_))
     rect_ = adjusted_new_rect;
 }
 

To complete my thought, if you have 2 side by side windows the occlusion of the tab contents will apply to the chrome UI behind it before the next window's tab contents will be considered.

If window A tab contents are considered first, they will occlude A's area in the UI, then A's area in the wallpaper. And B's area will occlude nothing right now unless it is *larger* than A. If it's not the occluded area will be: area of A (UI) + area of A (wallpaper)

The above changes the relationship when B is at least half as big as A. If B = A/2 in area then A's tab contents occlude its UI only. Then B's tab contents occlude its UI, and then B occludes the wallpaper. The total pixels considered occluded then is: area of A (UI) + area of B (UI) + area of B (wallpaper). And since B = A/2 that's equal to the case above.

So when B is larger than 1/2 of A replacing A with B is better in this scenario.

 Issue 678238  has been merged into this issue.

^ tested the patch in #12.  It does have the effect of letting the tab content occlude it's own window when it's > 1/2 the size of the other occluder.

However, the desktop is still only occluded by one window.  Pre-patch the largest window occluded the desktop.  Post-patch, the window with lowest z-stack occludes the desktop.

Right so with overview mode we get all the chrome UI occluded for all N windows instead of for 1 window. The wallpaper continues to be occluded about the same amount.. so this should mean roughly 1x overdraw throughout instead of 2x.

David is seeing something weird with 2 maximized windows though? He's looking at it a bit more.

Yeah, definitely an improvement for overview mode.

reveman@ Could you share your findings of 2 maximized windows with patch in comment #12? I tried to apply the patch and I don't see any overdraw problems.

In picture 1, there are 2 maximized window (no overdraw)
In picture 2, 2 maximized window with one extra window. 

Deleted: Screenshot from 2017-05-01 16:20:05.png 72.0 KB

	Screenshot from 2017-05-01 16:20:05.png 72.0 KB View Download

Deleted: Screenshot from 2017-05-01 16:20:20.png 58.8 KB

	Screenshot from 2017-05-01 16:20:20.png 58.8 KB View Download

If we can't find something this regresses then I think we should land it along with some unit tests to show that its working as intended.

I don't remember the exact case. Might have been a result of another issue that is now fixed. The screenshots above looks alright.

FYI, make sure you disable partial swap when using the overdraw tool as results can be misleading otherwise.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/34c7a895b3da858147c3bc836b23584a8c01410a

commit 34c7a895b3da858147c3bc836b23584a8c01410a
Author: yiyix <yiyix@chromium.org>
Date: Wed May 24 22:30:22 2017

Improve overdraw with multiple windows

When 2 windows are opened simultaneously (overlapped or non-overlapped)
namely window 1 and window 2, before this patch, defining the occluded
rect is used to computing the largest unionized rectangle that is
formed with these 2 windows and mark layers behind it occluded. However,
when we compute occlusion, each step is more likely to be occluded by
things added to this region more recently due to the way we build
scenes with overlapping elements adjacent to each other in the Z order.

For example, if a unionized rectangle uses area from both window 1
and window 2: if a pixel is from window 1, it occludes 1 layer of
overdrawing (drawing the pixel from the wallpaper); if a pixel is from
window 2, it occludes 2 layer of overdrawing (drawing the pixel from the
wallpaper and the pixel from browser UI).

In this patch, a weighted function is introduced to optimize the
calculate the unionized rectangle where the area in window 2 is
multiplied by 2, so the unionized rectangle is the rectangle with
the highest weight.

BUG= 680636 
TEST=SimpleEnclosedRegionTest.Union
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2866063002
Cr-Commit-Position: refs/heads/master@{#474451}

[modify] https://crrev.com/34c7a895b3da858147c3bc836b23584a8c01410a/cc/base/simple_enclosed_region.cc
[modify] https://crrev.com/34c7a895b3da858147c3bc836b23584a8c01410a/cc/base/simple_enclosed_region_unittest.cc