I chatted with David Reveman about frame eviction in exo and that sounded fine. I just chatted with Justin Novosad about offscreen canvas frame eviction and that also sounded fine. I am increasingly confident we can build a generic system here.

What's the one-sentence reasoning for placing it in mus-ws instead of mus-gpu? I'm presuming that the ws (or perhaps any other client) could indicate via the compositor API that it's likely to not need the the CF again.

The policy today is tuned around UI use cases. Switching tabs is a very important UI use case, so we keep a LRU cache of frames for hidden tabs. The GPU process doesn't have enough knowledge to apply that policy (it doesn't know that a given CompositorFrame belongs to a "tab" as opposed to a window or something else, it doesn't track "uses" of a tab, which is a purely UI concept), and I don't think it should.

Also, I don't think it makes sense to keep within the same cache frames for different levels of UI concepts. In particular it doesn't make sense to evict the frame for a window but not evict the frame for the visible tab within that window. Similarly, if we evicted the frames for all the tabs in a given window, it makes sense to evict the frame for the window itself (since we'll have to wait for a new renderer frame to restore the window anyway).

Lastly, the embedder of a frame needs to be able to deal with evicted frames, and provide a replacement. For example, if a tab is made visible, but we evicted the frame, we'll have to wait for the renderer to produce a new one, and deal with the fact that it may not be able to do so before the UI has to respond - at that point we need to blank out the tab (we replace it with a solid color layer, and even that causes problems if we're not thoughtful - see https://bugs.chromium.org/p/chromium/issues/detail?id=470669).

All these are things that I think don't belong in the GPU process. For that matter, I'm not even sure the window manager process even has enough information (but I guess I feel a little less bad about adding more metadata there to be able to effectively apply the policy?)

I started thinking more about this. I'm going to pick this up.

The key goal for frame eviction is to return resources to clients under low memory, right? The way frame eviction is implemented currently isn't ideal in a Mus environment.

1. Tell the embeddee to evict its CompositorFrame.
2. The embedder puts a SolidColorLayer up instead so that it no longer references the existing surface ID.

Suppose both the embedder and embeddee are untrusted clients? How do we make sure CompositorFrames are actually evicted? It seems like a trusted process needs to be responsible for kicking off the eviction, right and not the embeddee? 

This is fine because a trusted process IS doing the eviction today: the browser process. In the future, even the browser process won't necessarily be considered trusted by Mus.

+enne@, danakj@, jbauman@

The key goal of frame eviction is to keep the memory usage bounded as users open more tabs. It is not limited to low-memory situations, we do not want to use O(tabs) memory if only a few tabs are visible (1 per visible window).

Our latest thinking on this is:

1. There is a single CompositorFrame LRU cache in Mus-Gpu for everything that is unaware of UI concepts. These are CompositorFrames in Surfaces that are NOT currently drawn in the parent CompositorFrame. 

TODO(fsamuel, kylechar): We need a way to track Surfaces that are kept alive BUT not drawn. I'm not sure if referenced_surfaces is the right thing here.

2. When the cache is full (some bounded size), we evict the least recently used CompositorFrame.

3. If an evicted frame is referenced by visible parent, then surface synchronization (design doc coming soon) kicks in and the parent CompositorFrame is marked as "pending" until the child generates a CompositorFrame. In practice this means that the parent hiccups for up to 4 frames (jank) and will use a backup draw quad if the child is not ready: surface synchronization deals with this.

This is blocked on surface synchronization. If an evicted frame comes into view, we should block activation of the embedder's CompositorFrame until the child re-rasters and submits a new CompositorFrame.

Migrating Proj-Mustash-Mus to components Internals>Services>WindowService and Internals>Services>Ash

Bug label cleanup.

Cleaning up old Proj-Mustash labels.