It seems that Alt-Tab and "switch window" are very expensive in resources (memory and CPU).

Looking at the screenshot above, I'm struck by the fact that as free memory goes down, buff/cache goes up, and vice-versa.  It looks like memory is not being swapped to compensate for free memory going down.  I've also noticed this about the "switch window" UI too.  When that is invoked, again free memory goes way down, buff/cache goes way up, and swap isn't used much.

Hi, thanks for the repro case.

Yes, switching tab or window triggers various activities in the renderer for the newly exposed tab.  Additionally, depending on your window layout, the top renderer in each window may be kept active because parts of it may be visible.  So with 35 windows, you may have to share the CPUs among lots of processes and that could explain the slowdown.

What chromebook is this?

Other than the slowdown, I am not sure there is a problem with memory management.  You're right that little swap is used, but that seems fine because buff/cache includes the file cache, and most of those pages can usually be reclaimed quickly (they are just opportunistically holding file data which was read recently, in case it gets used again---otherwise the RAM would just sit there empty).

In any case, this is not a typical use case.  35 windows is a lot.  How many tabs total?

Thanks

#2 This is the Pixelbook i5.  168 tabs.  I upgraded from the Pro so I wouldn't run into as many tab discards, and haven't been disappointed about that; however not being able to quickly switch between windows has become an issue as reported here.

On my Pro, this issue crops up with many fewer tabs, and is accompanied by many tab discards, including "visible" tabs.

It works well until free memory gets below 200 mb.  That's the point at which the UI becomes completely unresponsive.  CPU usage also spikes at that point.  200 mb seems to be some sort of threshold.  Not sure why switching windows is using so much memory, I've not seen this on other OS's.

Thanks.

Slowdown also happens on my i5 PixelBook with many fewer windows (maybe 4-5), but with 3-4 Android apps open. Sometimes it outright freezes. Will try to get a reproducible sample when I have time.

Just wanted to add that I've very rarely experienced a completely smooth experience with Overview. It's always been laggy, both on my Pixel LS and now on the PixelBook, and I'm not sure if there's been much attention paid to optimizing it.

I'm seeing a lot of discarded tabs on my Samsung Chromebook Pro, just by Alt-tabbing through all my windows.  Prior to Alt-tabbing, the windows are not discarded.  Alt-tabbing through them causes many of them to be discarded.  Why is that behavior reasonable?

#6 as I mentioned in #2, exposing a tab doesn't just switch to another window but also triggers activities, including giving a higher priority to the process serving the tab.  In some cases the tab itself starts loading only when switched to it.  In other cases the exposure may trigger Javascript execution.  As the exposed tab requests RAM, other tabs are discarded when memory is running low.

Overview mode is particularly heavy because all tabs are exposed.

This is being worked on by the UI folks.  Unfortunately I cannot point you to the issues as they are internal only.

Sorry about this problem.  May I ask if this is a normal use case, or are you investigating the limits of the device?

In my experience, it's pretty bad on the i5, and under circumstances that were okay for instance on the Pixel LS: a few windows and a couple of Android apps. It's tolerable on the i7, so the difference could be 8GB vs 16 GB RAM.

#7 I typically run with lots of windows and tabs, not a test case.  I upgraded from the CB Pro to get more memory and avoid tab discards.  On the Pixelbook i5, while I'm not seeing tab discards, the overview and Alt-Tab are pretty unusable due to slow-downs and sometimes the mouse even stops working.  On the Pro, just cycling from one window to the next with Alt-Tab causes tabs to be discarded, which is odd, because those tabs were previously loaded and not causing discards.

My sense of the situation is that the Alt-Tab and overview are creating extreme memory pressure and causing the CPU to spike while the Chromebook tries to deal with the memory pressure.  The 16gb in the i7 might explain why its not as bad.

The memory pressure doesn't seem related to the actual tab activity (Javascript etc), rather it is caused by the implementation of the Alt-Tab and Overview features.  I'm pretty sure of this because Alt-Tab gets slower and slower as you cycle through the tabs (pressing alt-tab repeatedly), and free memory goes down down down, to the point where you cannot go any further or complete a full cycle through the tabs.  As soon as you stop, free memory goes back up, and everything is immediately fine (except on the Pro where many previously active, visible tabs are now discarded).  I don't quite understand why discards happen on the Pro but not the Pixelbook.  Ironically the discards make the Pro smoother and faster than the Pixelbook because memory gets freed up, and you can complete a full cycle of Alt-Tabs on the Pro.

You can see the memory going away and then returning in the attachment.  If the tabs were using that memory, it wouldn't come back like that.  Make sense?

wutao@ please triage

I ran some memory-infra traces while pressing the overview key and while doing Alt-Tab.  You can see in the attached that "cc" memory increases dramatically (by >1gb) during these activities.  Hope this helps!

Deleted: trace_Alt-Tab.json.gz 17.6 MB

trace_Alt-Tab.json.gz 17.6 MB Download

Here's the other trace (Overview), was too much to include both in one comment.

Deleted: trace_Overview.json.gz 19.9 MB

trace_Overview.json.gz 19.9 MB Download

Hi reveman@, does this sound like the mipmap used in window cycling and overview mode?

Actually, we have two new things in overview mode and window cycling: cache the render pass and create mipmap.

This looks like a leak in the browser process. 1.5 GiB of resource memory in cc for the browser seems too high unless there are more than 50 open windows?

The caching will add 15 MiB per window at most on these devices. And mipmaps add 1/3 more memory on top of that.

We should first track down what seams like a memory leak. After that, here are some suggestions for how we can improve memory usage. In the case of the window switcher, we can reduce the memory usage drastically by caching the down-scaled thumbnail instead of the full size window with mips. We can do that as the size of the thumbnail is not changing. We can also try to avoid generating thumbnails until they are visible. That can make a big difference when a larger number of windows are open.

Overview mode is harder as we animate in/out of that mode. Maybe limit the number of windows that get trilinear filtering to 8 or something? 8 fullscreen windows with mips require ~160 MiB of memory on the pixelbook.

#16 if overview mode could be made less "janky" by removing the animation, I'd definitely vote for that :)

We have a new proposal for overview mode animation, which will reduce the number of window animating, especially in tablet mode: issue 801465.

We could cache the down-scaled thumbnail in overview until we animate. That will likely improve the memory usage significantly once we switched to the new overview animation.

First, let's find out what the memory leak is. It's unclear how important it is to reduce this memory usage once we've fixed the leak.

#18 issue 801465 is not visible to me

Sorry to be a PIA, but is there any update on this since I can't see issue 801465?  Thanks!

issue 801465 is a new proposal for animation, did not resolve the root cause of this bug.

I can repro in the Alt-Tab case, that the available memory is getting less and when exiting the "window cycling", the available memory is back to the value before entering "window cycling" mode.

Is there a similar "leak" in the "overview mode"?

I will look where the memory leak comes from.

Thanks.  Yes, the leak occurs in "overview mode" too.  See the attachment in comment 13, captured while going into and then back out of overview mode.

#23, there might be different in overview mode. When I navigating in overview mode, I do not see decrease of memory. The consumption of memory was released when overview mode exit.

However, in the "window cycling/alt tab" case, the free memory decreases when using "tab" and looks like the memory is not always fully freed when exiting "window cycling". I can saw missing tiling during "window cycling" when opening 35 browser windows.

#24, during window cycling on a machine with only 4gb ram like my caroline, sometimes the tab will be discarded due to the memory being low, and the tile will be black.  On my Pixelbook with 8gb ram that doesn't happen.

I think what reveman@ was saying in #16 was that during "overview" and also during "switch window", the memory used is way too high, indicating a leak; but not necessarily after exiting the mode.

I've attached a screenshot of memory use on my Pixelbook showing what happens while going into overview mode and then coming out.  The memory gets very low, then returns to where it was.  It's very similar to what happens during window cycling.  The memory use is way to high during the operation, which causes slowness, jankiness, tab discards, etc.

Deleted: Screenshot 2018-01-31 at 6.15.09 PM.png 423 KB

	Screenshot 2018-01-31 at 6.15.09 PM.png 423 KB View Download

#25, thanks. There might be two issues:
1. The memory usage is too high for caching and mipmap in both overview and window cycling. 
2. The memory leak in window cycling, the memory goes down when switching.

reveman@, to explain 2, my guessing is that when windows are cycling from offscreen to onscreen, this might cause additional calculation/generation of mipmap, but at the same time, we did not release the old texture/cache?

#25, from your screenshot, the memory in the overview mode is kind of stable. But in screenshot of #0, the memory is decreasing in window cycling mode.
So there are two issues.

#27 I'm not sure what you mean. In screenshot of #0 the free memory is 13394 before window cycling and 13394 after too.

#28, what I meant is that, the memory values printed during window cycling is "696, 275, 183", it is decreasing and we saw tab discards.
While in the overview mode, the memory values is low ~200-300, but stable.

Also I get tab discards on caroline when using overview mode too.

#29, I rebooted and tracked free memory while doing "overview" and then "window cycling", one after the other.  Each uses a similar amount of memory, around 1.5GB.  See attached screen shots.  The one with command "free -tm -s 3" is during "overview" mode, while the one with "free -tm -s 8" is during "window cycling".

Hope this helps!

Deleted: Screenshot 2018-01-31 at 9.43.54 PM.png 242 KB

	Screenshot 2018-01-31 at 9.43.54 PM.png 242 KB View Download

Deleted: Screenshot 2018-01-31 at 9.47.09 PM.png 239 KB

	Screenshot 2018-01-31 at 9.47.09 PM.png 239 KB View Download

I do not see obvious "new" from the views code. Could be underlying gl_renderer request more memory to do calculation.

Here is what current window_cycle_list implementation:
1. It will create mirror_view for all windows and add to a mirror_container.
2. When "cycling/alt tab", only change the mirror_container's bound, i.e. for 50 windows, we have a huge mirror_container, but only set bound to make a small part of it visible.


reveman@, how easy to implement this only caching the down-scaled thumbnail.
At the view side, in "window cycling", there are only a few windows are visible, does it make sense to only calculate/cache the trilinear filter for the visible windows? Or if we want to make it simple, we only the selected or first window.

As for "overview" mode, if there are too many small windows, the quality improved by trilinear may not worth the cost of memory usage. We can limit the number of windows with trilinear (maybe only one window: the selected or first window). Or we only cache the down-scaled thumbnail.

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

commit ead73f584a60e1b228f5842395fd0161969ed904
Author: wutao <wutao@chromium.org>
Date: Sun Feb 11 23:25:36 2018

cros: Add a switch to turn off trilinear filtering.

Mipmap generation is not guaranteed to be GPU accelerated on all devices
that Chrome OS ships on, and without acceleration it is too slow to use
trilinear filtering.

In addition, some device drivers may not support correct mipmap generation.
We can use this flag as a workaround until driver bugs have been fixed.

This cl creates an ash switch so that we can turn off trilinear filtering.

Bug:  799501 , b/72298538
Test: Can create the flag and turn off the trilinear filtering.
Change-Id: Ia711fce0bc037a391f4bb610e73af32301de7a89
Reviewed-on: https://chromium-review.googlesource.com/908251
Commit-Queue: Tao Wu <wutao@chromium.org>
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: David Reveman <reveman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536011}
[modify] https://crrev.com/ead73f584a60e1b228f5842395fd0161969ed904/ash/public/cpp/ash_switches.cc
[modify] https://crrev.com/ead73f584a60e1b228f5842395fd0161969ed904/ash/public/cpp/ash_switches.h
[modify] https://crrev.com/ead73f584a60e1b228f5842395fd0161969ed904/ash/wm/overview/scoped_transform_overview_window.cc
[modify] https://crrev.com/ead73f584a60e1b228f5842395fd0161969ed904/ash/wm/overview/window_selector.cc
[modify] https://crrev.com/ead73f584a60e1b228f5842395fd0161969ed904/ash/wm/window_cycle_list.cc
[modify] https://crrev.com/ead73f584a60e1b228f5842395fd0161969ed904/ash/wm/window_mirror_view.h
[modify] https://crrev.com/ead73f584a60e1b228f5842395fd0161969ed904/chrome/browser/about_flags.cc
[modify] https://crrev.com/ead73f584a60e1b228f5842395fd0161969ed904/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/ead73f584a60e1b228f5842395fd0161969ed904/chrome/browser/flag_descriptions.h
[modify] https://crrev.com/ead73f584a60e1b228f5842395fd0161969ed904/tools/metrics/histograms/enums.xml

Will trilinear filtering be turned off for eve and caroline?  Which version of CrOS will this flag be in?  Does it reduce the memory usage and speed up the interface and prevent tab discards?

Thanks!

#38, the flag is default enabled. We will use the flag to debug other issues.

For the high memory usage, we will fix it by the proposal in #16 and #36.

Sorry if I'm being dumb, but by "default enabled" do you mean that trilinear filtering will be disabled by default?

Also which version of Chrome will this flag be in?

Thanks!

Trilinear filtering is turned on by defaut.
It is landed in ToT (M66).

Hi, any progress on fixing the high memory usage issue?

For Window cycle list: I found out the reason why the memory is getting lower. It is not memory leak, it is because the WindowMirrorView is inited when it is visible, therefore use more memory for render pass cache and trilinear filtering.

I will upload a cl soon to only use trilinear filtering when window is visible in window cycle list.

Hi,any progress on these?  On my new Pixelbook i7 with 16gb ram, I am still seeing extreme slowness in overview mode, as well as rendering errors and slowness in Window cycle list.  See attached for example of rendering errors where the Window title is missing and also the top part of the web page.

Deleted: 20180807_154029.jpg 3.2 MB

	20180807_154029.jpg 3.2 MB View Download

We will set "Trilinear Feature" default off until we figure out how to resolve the memory issue.

https://chromium-review.googlesource.com/c/chromium/src/+/1166199

I tried turning trilinear filtering off, and now Window cycle list works fine.

However overview mode still takes several seconds to render and then it is full of errors.  See attached screen image.

Deleted: 20180808_122603.jpg 2.7 MB

	20180808_122603.jpg 2.7 MB View Download

wpwoodjr@, the overview has different issue.
Please follow up with the other bug 862760. Thanks.

As a workaround, I use the Alt+<number> shortcut. If Chrome is the first app pinned on the shelf, I used Alt+1 to go carousel through all Chrome windows and it's super fast.

#47, please provide a link to 862760, I cannot find it.

wutao@, should I file a new bug?

wpwoodjr@, the bug 862760 is for internal.

It could be good to file a new bug for your case and I can cc to the right people.

Thanks!

#51 wutao@, I posted under this "meta bug": https://bugs.chromium.org/p/chromium/issues/detail?id=905388#c6