-
Notifications
You must be signed in to change notification settings - Fork 6k
[WIP] Recator API 'SceneBulder.addPicture' to return 'PictureEngineLayer' #32738
Conversation
| Picture picture, { | ||
| bool isComplexHint = false, | ||
| bool willChangeHint = false, | ||
| PictureEngineLayer? oldLayer, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if oldLayer is needed in this place, it doesn't look useful. Probability it makes more sense not to add it?
| /// {@macro dart.ui.sceneBuilder.oldLayer} | ||
| /// | ||
| /// {@macro dart.ui.sceneBuilder.oldLayerVsRetained} | ||
| PictureEngineLayer addPicture( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since PictureEngineLayer is returned here and can't be null, the related logic in web_ui must also be implemented in this PR. And I'm not familiar with web_ui, so I'm not sure if my implementation is correct.
In addition, when this PR prepare to land, we need to temporarily disable some tests in packages/flutter/test/rendering/layers_test.dart, Because the FakeSceneBuilder.addPicture returns null
c.f.
https://github.com/flutter/flutter/blob/94d7f5e6724d3e0c627a9ceb27e294c5c12ddebb/packages/flutter/test/rendering/layers_test.dart#L751-L781
Maybe we can consider changing the return value here to PictureEngineLayer?, so that we don't have to change the implementation of web_ui, and we don't have to disable layers_test.dart
|
I think the previous change you proposed would be much, much less intrusive than this change |
The API changing in this proposal should not be too big, although it can't do the same as the previous proposal without change the API at all. But in this proposal, we only need to change the return value of I verified that this proposal also works fine like the previous one. |
|
But compared to not having to update the API at all, it is a big change. Also consider that all code that manages pictures in the framework will now need to track the engine layer too. |
|
Your suggestion for the framework change sounds like you haven't actually tested if this can work? In particular, if the picture has been rebuilt then it should not be treated as an "oldLayer" when added to the tree. Where do you set engineLayer to null when the picture is rebuilt? |
|
The RepaintBoundary solves that issue by actually not rebuilding its layers unless a child is modified. Solving this for non-RepaintBoundary objects would require any RenderObject that holds on to a picture to do such tracking - which means it needs to be a RepaintBoundary, or at least participate in the concept of which parts of the tree to rebuild to the same extent as RPB does. |
@flar I tested it and it works. In the current implementation of flutter, the PictureLayer of the framework does not hold the engineLayer, which results in that when its parent's addToScene is called, even if the PictureLayer's flag _needsAddToScene is false, its addToScene will also be called. And if PictureLayer also has engineLayer, then addRetained will be called in this case. So the key to making it work is to let PictureLayer hold its own engineLayer, so that the DisplayListLayer of the engine layer can be stable.Of course, like the previous proposal, this also requires flutter/flutter#101952 |
|
I sort of disagree with this implementation - we don't need the display list layer to be stable if the picture is stable. Assuming the user or the framework is keeping the picture stable, then the kLayer caching strategy should work. To do so, it must use the display list ID as the cache key. This sort of approach seems like way more work. |
|
@jonahwilliams @flar It seems that none of you like this proposal. Maybe we can move on to the previous proposal :) |
|
This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold. |
fix flutter/flutter#101872
framework change probably looks like this
Pre-launch Checklist
writing and running engine tests.
///).