Same-sized windows not considered occluded |
||||||||||
Issue descriptionChrome Version: 71.0.3549.0 OS: macOS What steps will reproduce the problem? (1) Open a window to a page that burns CPU (ongoing animation or a media player is ideal). Make the window the full size of the screen. (2) Open a second window, which should be created at the same size as the first one, to about:blank. (3) Look at the Task Manager. (4) Make the "heavy" window smaller than the blank window and repeat the test in (3) (move the blank window in front, then check the task manager) What is the expected result? The CPU usage of the background page drops dramatically while it's in the background. What happens instead? While the background page is the same size as the foreground page, its CPU usage does not drop. When it's slightly smaller, it does drop. I couldn't test this on Windows because the background tab always used full CPU. Maybe there's no occlusion tracking on Windows?
,
Sep 11
,
Sep 20
,
Sep 20
,
Sep 26
,
Oct 26
,
Oct 29
,
Nov 13
Easy repro case: 1) Open window 1 to the attached HTML page. 2) Open window 2 to about:blank or similar. Check task manager - both windows should be using ~0 CPU. 3) Click the "Busy" button in window 1. Check task manager - the "busy" page should be using around 6-7% CPU as it wakes up at 100Hz. 4) Make both windows the exact same size - the easiest way to do this is to just drag them to the maximum allowed size. 5) Vary which window is in front Check task manager - the "busy" page will use 6-7% CPU consistently. 6) Drag the "busy" window to be a bit smaller, and switch to the blank window Check task manager - the "busy" page will be at 0% CPU.
,
Nov 13
Huh. We don't receive occlusion change notices at all in this situation - NSWindowDidChangeOcclusionStateNotification appears not to be delivered. I think the occlusion notifications are only delivered when parts of the window are shown/hidden, but the logic in WebContentsViewMac needs to also listen for the Widget's activation state to change. Otherwise, no notifications arrive about occlusion state at all. For example, try this: 1) Open window 1 to busy.html 2) Open window 2 to about:blank 3) Move both windows into the top right corner 4) Start the busy loop in window 1 5) Make window 2 larger than window 1 6) Vary which window is active In all cases, the busy loop keeps running at 6% CPU or so, so something is pretty broken here.
,
Nov 13
Actually, #9 is wrong - everything works fine so long as the windows do not share an edge. I don't really know why this is but it doesn't seem urgent to me, so I'm kicking it out of M72 and my queue.
,
Nov 19
***Mass UI Triage*** As per comment #11 |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by sdy@chromium.org
, Sep 11