Dana, is this something you can help investigate?

Where in that screenshot are you seeing a bug?

Oh, reading doc..

Sorry ya I'm not understanding. It says the bottom window is failing completely, where exactly? The red area is from the shadow of the window above it. The top left corner of the tab contents isn't occluded because its a corner of the whole tab contents surface. I'm not sure why the whole surface is green but that's happening also where the top window isn't overlapping?

Can you help me understand what is failing?

Blue is 1x overdraw and green is 2x overdraw. 1x overdraw for the shadow is of course expected.

Problem 1: 1x overdraw for the opaque area of the top-most window is unnecessary. Occlusion culling failing for the bottom most shadow that is underneath the top window is not too surprising as that optimization might be non-trivial to get right. However, bottom-most client area being drawn even though the top-most opaque client area covers it is a surprise and bad as it means that if we have two maximized windows open, we'll draw them both even if the top window covers the bottom completely. It's especially surprising as we seem to handle the tab-strip area correctly.

Problem 2: 2x overdraw for the visible client area of the bottom window. That's a huge surprise and terrible for performance. These are both about:blank pages and there's no good reason for the bottom window to have overdraw in the client area when the top window with the same contents does not.

> However, bottom-most client area being drawn even though the top-most opaque client area covers it is a surprise

The client area is being drawn because it's not fully occluded right? If you cover the whole window does it keep drawing the client area? We don't deal with occlusion of a corner of an area.

> It's especially surprising as we seem to handle the tab-strip area correctly.

The tab strip is made up of individual tiles so some of those tiles are fully occluded. The tab contents is a single surface draw quad. This will be helped by moving draw occlusion into the display compositor, as then individual quads in the tab contents can be occluded like they are in the tab strip if they are fully covered. https://bugs.chromium.org/p/chromium/issues/detail?id=672929

> Problem 2: 2x overdraw for the visible client area of the bottom window. That's a huge surprise and terrible for performance.

I agree, but its also for parts that aren't occluded so I'm not sure what that has to do with occlusion - does it?

> > However, bottom-most client area being drawn even though the top-most opaque client area covers it is a surprise
> 
> The client area is being drawn because it's not fully occluded right? If you cover the whole window does it keep drawing the > client area? We don't deal with occlusion of a corner of an area.
> 
> > It's especially surprising as we seem to handle the tab-strip area correctly.
> 
> The tab strip is made up of individual tiles so some of those tiles are fully occluded. The tab contents is a single surface > draw quad. This will be helped by moving draw occlusion into the display compositor, as then individual quads in the tab contents can be occluded like they are in the tab strip if they are fully covered. https://bugs.chromium.org/p/chromium/issues/detail?id=672929

Makes sense. I'll verify that a fully occluded client area is not causing overdraw asap. That will hopefully avoid overdraw for the two maximized windows case I mentioned earlier. Any estimate on how long it will take to move occlusion culling to the display compositor? Is anyone actively working on this?

> 
> > Problem 2: 2x overdraw for the visible client area of the bottom window. That's a huge surprise and terrible for performance.
> 
> I agree, but its also for parts that aren't occluded so I'm not sure what that has to do with occlusion - does it?

Looks like the wallpaper that is occluded is drawn and maybe also whatever other layer we might have below the client area which is also occluded but it could of course be something else going on here. I changed the title from occlusion to overdraw until we have more details. Whatever it is, we have an opaque area that the compositor is aware of but for some reason we decide to draw to that area multiple times when producing output. Occlusion culling code in the compositor seemed like a good starting point for trying to find the root cause. Is there an another area that would be better to start looking at? 

> Any estimate on how long it will take to move occlusion culling to the display compositor? Is anyone actively working on this?

enne figures it's a week of work, no one is doing it right now.

> Occlusion culling code in the compositor seemed like a good starting point for trying to find the root cause. Is there an another area that would be better to start looking at? 

Green is 3 draws right? If the tab contents were not considered opaque then we'd draw the wallpaper, ui, and tab contents, which is what this looks like..

But I'm not really clear what the overdraw is in the top-most window even inside the tab contents. Is that the wallpaper tiles in the corners? Or is it he UI window behind the tab contents (do they move when you move the window around)? I would actually expect both but I don't see both there..

> enne figures it's a week of work, no one is doing it right now.

OK, sounds good. After fixing other issues we can evaluate how important this is and maybe increase the priority if necessary. 

I verified that a small window completely occluded by a larger window is properly detect and no unnecessary overdraw is taking place in that case. If I maximize two windows then I'm not getting any overdraw in the client area but 2x overdraw in the tab-strip area.

> Green is 3 draws right? If the tab contents were not considered opaque then we'd draw the wallpaper, ui, and tab contents, which is what this looks like..

Correct. The weird part is that the tab contents is clearly opaque as if I raise the window to the top then the overdraw goes away but we instead get the same bad overdraw for the other window.

> But I'm not really clear what the overdraw is in the top-most window even inside the tab contents. Is that the wallpaper tiles in the corners? Or is it he UI window behind the tab contents (do they move when you move the window around)? I would actually expect both but I don't see both there..

The tiles in the corners seem to line up with the wallpaper tiles. If I move the window slightly then those tiles stay in the same place on screen. They goes away when maximizing the window.

I'll get this debug feature landed asap so you can easily play with on your own.