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

Add support for images in display lists. #32268

Merged
merged 10 commits into from
Mar 30, 2022

Conversation

chinmaygarde
Copy link
Member

No description provided.

@chinmaygarde chinmaygarde added the Work in progress (WIP) Not ready (yet) for review! label Mar 25, 2022
@flutter-dashboard flutter-dashboard bot added embedder Related to the embedder API platform-ios labels Mar 25, 2022
@chinmaygarde chinmaygarde force-pushed the drawimage branch 3 times, most recently from a52b4c1 to 45e8528 Compare March 28, 2022 21:44
@chinmaygarde chinmaygarde requested review from zanderso, flar and bdero March 28, 2022 22:46
@chinmaygarde chinmaygarde removed the Work in progress (WIP) Not ready (yet) for review! label Mar 28, 2022
@chinmaygarde
Copy link
Member Author

This is good for a review now. This depends on flutter/impeller#102 in Impeller and the DEPS have been pointed to the fork temporarily for the presubmits.

@zanderso
Copy link
Member

Looks like a bunch of the DrawImage display list unit tests are failing, like:

[ RUN      ] DisplayList.SingleOpDisplayListsRecapturedViaSkCanvasAreEqual
../../flutter/display_list/display_list_unittests.cc:909: Failure
Value of: dl->Equals(*sk_copy)
  Actual: false
Expected: true
DrawImage[variant 1] == sk_copy

Copy link
Contributor

@flar flar left a comment

Choose a reason for hiding this comment

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

I looked mainly at the /display_list, /flow, /flow/layers, and canvas.cc and image.cc and mainly left some TODO suggestions and nits.

Perhaps someone else more familiar with how we manage the codecs and shell stuff could look at those parts, otherwise I'll try again tomorrow...

@@ -24,7 +25,7 @@ SurfaceFrame::SurfaceFrame(sk_sp<SkSurface> surface,
FML_DCHECK(submit_callback_);
if (surface_) {
canvas_ = surface_->getCanvas();
} else {
} else if (display_list_fallback) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this then have a final "else" that notifies someone that we gave up on canvas/recorder? If that can't happen, do we need the if part of this else-if?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, the embedder depends on there being no surface (and hence its canvas) when running with composition enabled. This was added to make sure that use case (and its tests) are supported.


SkIRect DlImage::bounds() const {
auto size = dimensions();
return SkIRect::MakeXYWH(0, 0, size.fWidth, size.fHeight);
Copy link
Contributor

Choose a reason for hiding this comment

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

There are SKIRect factories for SkISize and int w,h...

Copy link
Member Author

Choose a reason for hiding this comment

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

Done. I was hoping to just remove these convenience methods but they did make porting over the old code easier. I'll file a followup.

@flar
Copy link
Contributor

flar commented Mar 29, 2022

Looks like a bunch of the DrawImage display list unit tests are failing, like:

[ RUN      ] DisplayList.SingleOpDisplayListsRecapturedViaSkCanvasAreEqual
../../flutter/display_list/display_list_unittests.cc:909: Failure
Value of: dl->Equals(*sk_copy)
  Actual: false
Expected: true
DrawImage[variant 1] == sk_copy

I think the sk_copy's are DL -> SkCanvas -> DL conversions where we lose the Dl-ness of the DlImage and so we may have to disable them. I think there is a way to set a value in the records to disable them (sk_testing_invalid suggests setting the sk_op_count fields to negative numbers as is done with the DrawPicture and DrawDisplayList cases - do a case sensitive search for those strings and you should see how that is done)

@chinmaygarde
Copy link
Member Author

All presubmits (except the engine tree check) are passing. I've landed the Impeller patch and updated the DEPS. This is good for another review.

@chinmaygarde
Copy link
Member Author

The guidance for g3 rolls is the same as before. All TU's with the _impeller suffix can be ignored. The TUs that do reference these files do so behind a macro which is absent in internal builds.

@@ -4,13 +4,35 @@

#include "flutter/lib/ui/painting/image_decoder.h"

#include <algorithm>
Copy link
Member

Choose a reason for hiding this comment

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

I think we added these explicit includes of <algorithm> for the g3 build. Please verify that they went along with the code that got shuffled around.

Copy link
Member Author

Choose a reason for hiding this comment

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

I removed all existing headers and tried to include what was being used as there were a few spots where there were spurious includes. But you're right, std::max would need to include algorithm but in the _skia TU. I'll add it there.

// found in the LICENSE file.

#include "flutter/lib/ui/painting/image_decoder_skia.h"

Copy link
Member

Choose a reason for hiding this comment

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

Like do we need to retain #include <algorithm> here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@@ -46,7 +48,7 @@ class CanvasImage final : public RefCountedDartWrappable<CanvasImage> {
private:
CanvasImage();

flutter::SkiaGPUObject<SkImage> image_;
sk_sp<DlImage> image_;
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm concerned that we moved the SkiaGPUObject wrapper down to an unnecessary level.

That wrapper exists because lib/ui/painting/image.h lives in a Dart wrapper and its lifetime is determined by Dart and its GC in a Dart isolate/thread. That isolate/thread doesn't have the ability to free things like images and so the SkiaGPUObject wrapper forwards the unref to a thread that can.

From this object, that forwarding is needed.

But, when a reference from this field is handed off to the engine, it is managed by a thread that can unref and free images, so it no longer needs the SkiaGPUObject protection. You've just moved that indirection down into the engine object which means that every time we get rid of one of these DlImage wrappers, we'll have to forward that unref to a thread.

Shouldn't this be held in a SkiaGPUObject here and then the DlObject you create here doesn't need to use a SkiaGPUObject?

Copy link
Member Author

Choose a reason for hiding this comment

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

Using a SkiaGPUObject here would mean that Impeller textures would require an unnecessary thread hop on each collection. Impeller has no restriction on where textures may be collected and it (thread hops) seemed like something that ought to be left to the backend and not performed by default.

///
/// @attention Unlike all other methods on the platform view, this will be
/// @attention Unlike all other methods on the platform view, this will
/// be
Copy link
Contributor

Choose a reason for hiding this comment

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

odd wrapping here...

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

Copy link
Contributor

@flar flar left a comment

Choose a reason for hiding this comment

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

I spotted a nit about odd wrapping and left a comment.

Everything looks good to me, but I only had passing familiarity with the code in the shell directory so it would be good to get a second pair of eyes on that. Also, much of the impeller decoder appears to happen somewhere else compared to the skia decoder and I'm going to trust that that "somewhere else" is doing the right thing for now.

@chinmaygarde chinmaygarde reopened this Mar 30, 2022
@chinmaygarde chinmaygarde added the waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land. label Mar 30, 2022
@fluttergithubbot
Copy link
Contributor

This pull request is not suitable for automatic merging in its current state.

@fluttergithubbot fluttergithubbot removed the waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land. label Mar 30, 2022
@chinmaygarde
Copy link
Member Author

Hmm, the cancellation of build_and_test_linux_unopt_debug is making the presub trip over the tree status. The cancellation was to work around the .ci.yaml validation failure.

@chinmaygarde chinmaygarde added the waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land. label Mar 30, 2022
@chinmaygarde
Copy link
Member Author

Whew, the tree is finally green.

@chinmaygarde chinmaygarde merged commit 6dd43e6 into flutter:main Mar 30, 2022
@chinmaygarde chinmaygarde deleted the drawimage branch March 30, 2022 20:31
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Mar 30, 2022
zanderso pushed a commit to flutter/flutter that referenced this pull request Mar 31, 2022
* cb9232b [web] webOnlyWarmupEngine + js-interop APIs (flutter/engine#32017)

* 88b7f72 [macOS] Generate gen_snapshot_$arch by default (flutter/engine#32326)

* 6dd43e6 Add support for images in display lists. (flutter/engine#32268)

* a1106da [web] Make "felt build" wait for both engine and canvaskit builds (flutter/engine#32308)
@kevmo314
Copy link

kevmo314 commented Jun 3, 2022

Hi, I think this PR is causing a crash in our app: flutter/flutter#105315

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
embedder Related to the embedder API platform-ios waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants