Multiple visual regressions after enabling buffered container framebuffer clipping by default

Opening as issue as I’m unsure on how to proceed.

Found at least three:

multiplayer lounge	now playing overlay	mania default skin (doesn’t look too broken, but is too flat)

Root case in all three usages is the same: it is combining the clipping option with CacheDrawnFrameBuffer. Using both in conjunction makes it so that the framebuffer is only ever clipped once, so if i.e. the buffered container is only partially visible when entering the screen, the cached framebuffer will have that initial too-small clipped size forevermore. In all above usages the buffered container sweeps/moves into the screen bounds and the framebuffer is clipped and cached too early.

Two fixes seem obvious - either reverting the clipping on-by-default and then adding clipping back to slider paths to fix the aspire breakage, or applying game-local clipToRootNode: false specs to all places that specify CacheDrawnFrameBuffer and look broken.

[peppy]

Starting to think the setting should not be exposed, but hard-coupled with CacheDrawnFrameBuffer instead. I can’t immediately think of a case where clipping when not caching would be visible in any way, and the chance of someone using caching but also wanting to clip to the screen bounds seems quite low (@smoogipoo brought up mania, but i don’t see how clipping is what we want for the case of mania as they are caching currently, which would cause the notes to be cut off in weird ways if enabled).

Will wait for further opinions on the matter.

[smoogipoo]

Depends on how bad the performance is. As you’ve mentioned, it’s two nested buffered containers.