-
Notifications
You must be signed in to change notification settings - Fork 6k
Remove single window assumption from SceneBuilder #41559
Conversation
337f35a
to
ae2c065
Compare
@jonahwilliams This PR should be ready for review, can you take a look? |
Please don't add parameters we'd need to support indefinitely for functionality we're going to remove in < 1 year. I would instead default the physical shape layer to use a 2.0 DPR. |
Here is a draft PR to delete PML: #41593 I'll see if this is landable in the near term. |
@jonahwilliams I've removed the extra parameter. Now they fetch the pixel ratio from window 0 with a fallback of 2.0f. Of course, it would be easier if your change could land. :) |
Also cc @goderbauer |
Looks like I missed once place , Canvas.cc actually depends on the device pixel ratio in Canvas::drawShadow:
We'll need to add support for providing the device pixel ratio on the framework side if this is used for real |
This is more or less just multiplied with the provided elevation: https://github.com/flutter/engine/blob/main/impeller/display_list/dl_dispatcher.cc#L1113 The impeller code is based on the Skia code. So technically we could make this work today by multiplying elevation by DPR in the framework, but that would break folks using the canvas interface |
@jonahwilliams I've created an issue for It does not affect this PR though, does it? |
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.
Overall this makes sense to me, deferring to the engine experts for details.
lib/ui/compositing/scene.cc
Outdated
@@ -23,6 +23,8 @@ | |||
|
|||
namespace flutter { | |||
|
|||
static constexpr float kFallbackPixelRatio = 2.0f; |
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.
This should probably have a comment answering questions like: Why is this 2.0? When do we fallback to this? Is this just meant to support legacy behavior and new logic should not use this constant? Or when should new logic use this constant?
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 see that this is kinda explained on defaultViewPixelRatio, might be worthwhile to link to that here)
lib/ui/compositing/scene.h
Outdated
// {Preroll,Paint}Context.frame_device_pixel_ratio, remove this method and its | ||
// related logic. | ||
// https://github.com/flutter/flutter/issues/125720 | ||
static float defaultViewPixelRatio(); |
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.
Can we give this a name that clearly indicated that this is legacy behavior and new code should not depend on this? Maybe we can replace default
with legacy
or something like that... The "default" should be to not assume a specific view or DPR.
@@ -20,6 +20,8 @@ | |||
|
|||
namespace flutter { | |||
|
|||
const uint64_t kFlutterDefaultViewId = 0llu; |
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.
Should this be "implicitView" instead of default view? We are trying to remove the annotation that flutter has a default view. In some modes, it may run with an implicitly created view, though...
Engine PR: flutter/engine#41593 This must land first We should remove these, as they've been deprecated for a while. On the engine side of things, the physical model layer is the only one which requires the device pixel ratio, so deleting it will allow us to simplify the layer tree code in flutter/engine#41559
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.
LGTM
…126175) flutter/engine@6b467df...758cbad 2023-05-05 jason-simmons@users.noreply.github.com [Impeller] Do not free a Vulkan command buffer if its command pool has already been destroyed (flutter/engine#41761) 2023-05-05 dkwingsmt@users.noreply.github.com Remove single window assumption from SceneBuilder (flutter/engine#41559) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC jimgraham@google.com,rmistry@google.com,zra@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
This PR fixes flutter/flutter#112202.
Scene
is no longer tied to views, but receives method arguments for view properties, clearing the path to multiview Flutter.Scene
no longer creates aLayerTree
on construction, but only part of the config. When a output method is called (toImage
,toImageSync
, ortakeLayerTree
), theLayerTree
is constructed on the spot. In this way, allLayerTree
s return to beingunique_ptr
s instead ofshared_ptr
s, reverting part of #35608 . AndScene
no longer needs to disfunction after onetakeLayerTree
, since the layer tree config is never really taken away.A
device_pixel_ratio
is now added to the parameter list ofEngine::Render
andAnimator::Render
.Pre-launch Checklist
///
).If you need help, consider asking for advice on the #hackers-new channel on Discord.