Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Remove single window assumption from SceneBuilder #41559

Merged
merged 16 commits into from
May 5, 2023

Conversation

dkwingsmt
Copy link
Contributor

@dkwingsmt dkwingsmt commented Apr 27, 2023

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 a LayerTree on construction, but only part of the config. When a output method is called (toImage, toImageSync, or takeLayerTree), the LayerTree is constructed on the spot. In this way, all LayerTrees return to being unique_ptrs instead of shared_ptrs, reverting part of #35608 . And Scene no longer needs to disfunction after one takeLayerTree, since the layer tree config is never really taken away.

A device_pixel_ratio is now added to the parameter list of Engine::Render and Animator::Render.

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
  • I listed at least one issue that this PR fixes in the description above.
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
  • I updated/added relevant documentation (doc comments with ///).
  • I signed the CLA.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@dkwingsmt dkwingsmt force-pushed the layer-tree-content-2 branch from 337f35a to ae2c065 Compare April 28, 2023 03:53
@dkwingsmt dkwingsmt requested a review from jonahwilliams April 28, 2023 19:22
@dkwingsmt
Copy link
Contributor Author

@jonahwilliams This PR should be ready for review, can you take a look?

@jonahwilliams
Copy link
Member

The dart:ui methods Scene.toImage and Scene.toImageSync receive a new parameter pixelRatio each. This parameter does not change the output dimension but only controls the deprecated physical shape models (PhysicalShapeLayer). We should also modify the framework to pass in the devicePixelRatio argument.

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.

@jonahwilliams
Copy link
Member

Here is a draft PR to delete PML: #41593

I'll see if this is landable in the near term.

@dkwingsmt
Copy link
Contributor Author

dkwingsmt commented Apr 28, 2023

@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. :)

@dkwingsmt
Copy link
Contributor Author

Also cc @goderbauer

@jonahwilliams
Copy link
Member

Looks like I missed once place , Canvas.cc actually depends on the device pixel ratio in Canvas::drawShadow:

  // Not using SafeNarrow because DPR will always be a relatively small number.
  SkScalar dpr = static_cast<float>(UIDartState::Current()
                                        ->platform_configuration()
                                        ->get_window(0)
                                        ->viewport_metrics()
                                        .device_pixel_ratio);

We'll need to add support for providing the device pixel ratio on the framework side if this is used for real

@jonahwilliams
Copy link
Member

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

@dkwingsmt
Copy link
Contributor Author

dkwingsmt commented May 1, 2023

@jonahwilliams I've created an issue for Canvas: flutter/flutter#125780

It does not affect this PR though, does it?

Copy link
Member

@goderbauer goderbauer left a 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.

@@ -23,6 +23,8 @@

namespace flutter {

static constexpr float kFallbackPixelRatio = 2.0f;
Copy link
Member

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?

Copy link
Member

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)

// {Preroll,Paint}Context.frame_device_pixel_ratio, remove this method and its
// related logic.
// https://github.com/flutter/flutter/issues/125720
static float defaultViewPixelRatio();
Copy link
Member

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;
Copy link
Member

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...

auto-submit bot pushed a commit to flutter/flutter that referenced this pull request May 2, 2023
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
Copy link
Member

@jonahwilliams jonahwilliams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dkwingsmt dkwingsmt merged commit 67d18ed into flutter:main May 5, 2023
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request May 5, 2023
auto-submit bot pushed a commit to flutter/flutter that referenced this pull request May 5, 2023
…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
@dkwingsmt dkwingsmt deleted the layer-tree-content-2 branch July 11, 2023 17:58
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove single window assumption from SceneBuilder
4 participants