mirror of
https://github.com/flutter/flutter.git
synced 2026-02-20 02:29:02 +08:00
7553282a55
With this PR, backing stores are labeled with view IDs. When the engine requests the embedder to create a backing store, the engine will promise that it will only be used for a specific view. This follows the design doc http://flutter.dev/go/backing-stores-for-multi-view-partial-repaint, so that backing stores can be used as a front surface that retains its content last frame. The engine will create a render target cache for each view to cache backing stores separately. ### Alternative design The separate render target cache for each view is not needed to implement the design doc, since all usages described in the design doc avoids the engine cache. Instead, we can make the engine still only manage one render target cache for all views, and backing stores in it are interchangeable across views. We might describe the behavior in this way: * In general, the view ID is just provided to the creating callback as information. (This is how it is seen when the engine cache is avoided.) * If the engine cache is used, then the created backing store might not be immediately collected, and might be reused for different views. But it's really hard to explain the mechanism and the result is really confusing (as can be seen from my attempt). Why is there a view ID but it's not used, and if you enable the engine cache it's not even followed? That's why I chose the current approach. Feel free to suggest otherwise for this. [C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style