Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[display_list] paint cleanup. #168082

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

jonahwilliams
Copy link
Member

Reduce the number of places where we convert flutter paint to DLpaint and remove unused tonic overrides. Also does a pass on dl_paint/builder to remove places we accidentally incremented/decrement shared_ptr ref counts

@github-actions github-actions bot added the engine flutter/engine repository. See also e: labels. label Apr 30, 2025
@@ -369,17 +370,17 @@ void DisplayListBuilder::SetAttributesFromPaint(
setStrokeJoin(paint.getStrokeJoin());
}
if (flags.applies_shader()) {
setColorSource(paint.getColorSource().get());
setColorSource(paint.getColorSourcePtr());
Copy link
Member Author

Choose a reason for hiding this comment

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

Use the ptr APIs directly so we don't increment + decrement the shared_ptr

Copy link
Contributor

Choose a reason for hiding this comment

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

Doesn't it have a shared_ptr interface to avoid the copy? Wouldn't that be better?

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 don't think it matters since we're not storing anything.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I see you are just now adding the shared_ptr setters. Woot!

Also, builder often copies the object to inline it anyway, but maybe we should reconsider that? I guess if ColorSource objects tend to be fast-copy then it's OK, but otherwise, storing a shared_ptr to the original would be desireable and that can't happen when you've done Ptr().

These could also be made shared_from_this compatible.

(Once upon a time I created a better sk_sp as dl_sp and it solved all of these issues. ;)

Copy link
Contributor

Choose a reason for hiding this comment

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

The issue here is that setColorSource can call onSetColorSource if the objects are different which needs a shared object. This should have some more refactoring otherwise we are recreating the object inside onSetColorSource.

We need setColorSource(ptr) because builder implements DlOpReceiver for copying of data. I might be able to get rid of that eventually, but until then perhaps the SetAttriutesFrom method should do its own comparisons and onSetColorSource takes a shared_ptr (ref). Thus, the DlOpReceiver version might need to call shared(), but not the one that syncs with a paint. Another issue is that if it is null then you can't call shared(). :(

Copy link
Member Author

Choose a reason for hiding this comment

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

hmm, yeah we want to avoid calling shared_from_this if possible since that does a weak ptr lock. Instead I'll change the setCall to take a refer and then we can avoid the shared call when non-null.

Copy link
Contributor

Choose a reason for hiding this comment

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

There is no shared_from_this currently. We have shared() which instantiates a whole new copy inside a shared_ptr. It's even worse than a weak ptr lock...?

Copy link
Member Author

Choose a reason for hiding this comment

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

eh, then it will be fine. I could keep refactoring this for a while but since I'm about to go OOO maybe call this good enough?

Copy link
Contributor

Choose a reason for hiding this comment

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

I have no objections and @gaaclarke already approved it. I think these changes move us forward.

Copy link
Member Author

Choose a reason for hiding this comment

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

ty!

@@ -1823,7 +1824,7 @@ bool DisplayListBuilder::AdjustBoundsForPaint(DlRect& bounds,
}

if (flags.applies_mask_filter()) {
auto filter = current_.getMaskFilter();
const DlMaskFilter* filter = current_.getMaskFilterPtr();
Copy link
Member Author

Choose a reason for hiding this comment

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

Only need the ptr here, same as usages for image/color filter below.

@@ -329,25 +329,25 @@ class DisplayListBuilder final : public virtual DlCanvas,
}
// |DlOpReceiver|
void setColorSource(const DlColorSource* source) override {
if (NotEquals(current_.getColorSource(), source)) {
if (NotEquals(current_.getColorSourcePtr(), source)) {
Copy link
Member Author

Choose a reason for hiding this comment

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

compare the ptrs so we avoid the shared_ptr increment/decrement.

@@ -123,57 +123,77 @@ class DlPaint {
return *this;
}

std::shared_ptr<const DlColorSource> getColorSource() const {
const std::shared_ptr<const DlColorSource>& getColorSource() const {
Copy link
Member Author

Choose a reason for hiding this comment

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

return a ref so that callers that specify a const ref don't increment/decrement.

Copy link
Member

Choose a reason for hiding this comment

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

Isn't this sufficient alone to get rid of all those increment decrements, so the getColorSourcePtr calls aren't required?

Copy link
Member Author

Choose a reason for hiding this comment

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

in theory, yes, but since we were calling getColorSource().get() anyway its still an improvement imo

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, get().get() should be outlawed.

DlPaint& setColorSource(std::shared_ptr<const DlColorSource> source) {
color_source_ = std::move(source);

DlPaint& setColorSource(std::nullptr_t source) {
Copy link
Member Author

Choose a reason for hiding this comment

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

Add nullptr_t overloads. Overload resolution for passing nullptr literal is ambiguous between selecting the raw ptr or shared_ptr. If the shared_ptr path is selected we will construct and destroy a shared_ptr.

@@ -209,120 +209,4 @@ const DlPaint* Paint::paint(DlPaint& paint,
return &paint;
}

void Paint::toDlPaint(DlPaint& paint, DlTileMode tile_mode) const {
Copy link
Member Author

Choose a reason for hiding this comment

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

This method is almost the same as the above conversion, expect it doesn't use flags. Remove it and give the draw paragraph code some flags.

} // namespace flutter

namespace tonic {
Copy link
Member Author

Choose a reason for hiding this comment

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

Unused

@@ -21,7 +22,9 @@ TEST_F(ShellTest, ConvertPaintToDlPaint) {
Dart_GetField(dart_paint, tonic::ToDart("_objects"));
Dart_Handle paint_data = Dart_GetField(dart_paint, tonic::ToDart("_data"));
Paint ui_paint(paint_objects, paint_data);
ui_paint.toDlPaint(dl_paint, DlTileMode::kClamp);

ui_paint.paint(dl_paint, DisplayListOpFlags::kDrawPaintFlags,
Copy link
Member Author

Choose a reason for hiding this comment

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

Lets test the API that is actually used for most draws...

@jonahwilliams jonahwilliams marked this pull request as ready for review April 30, 2025 18:55
@jonahwilliams jonahwilliams requested review from gaaclarke and flar April 30, 2025 18:55
@@ -123,57 +123,77 @@ class DlPaint {
return *this;
}

std::shared_ptr<const DlColorSource> getColorSource() const {
const std::shared_ptr<const DlColorSource>& getColorSource() const {
Copy link
Member

Choose a reason for hiding this comment

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

Isn't this sufficient alone to get rid of all those increment decrements, so the getColorSourcePtr calls aren't required?

return *this;
}
DlPaint& setColorSource(const DlColorSource* source) {
color_source_ = source ? source->shared() : nullptr;
return *this;
}
DlPaint& setColorSource(std::shared_ptr<const DlColorSource> source) {
Copy link
Contributor

Choose a reason for hiding this comment

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

What if this took a shared_ptr&?

Copy link
Member

Choose a reason for hiding this comment

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

There's the same number of copies in the worst case, in the best case (where someone has an rvalue in setColorSource) it's less.

Copy link
Member

Choose a reason for hiding this comment

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

(the current implementation)

@flar
Copy link
Contributor

flar commented Apr 30, 2025

I think this eliminates some of the ref count work. I'm happy if @gaaclarke is happy, but I think this entire mechanism should be reworked internally because when the attribute changes we end up going through Ptr->needs shptr->calls shared(). and that could/should be eliminated.

@flar
Copy link
Contributor

flar commented Apr 30, 2025

Another unnecessary inc:

return paint.getColorSource() ||

@jonahwilliams
Copy link
Member Author

That call should be fine since we're just checking the const ref, no increment/decrement.

@jonahwilliams jonahwilliams added the autosubmit Merge PR when tree becomes green via auto submit App label May 1, 2025
@auto-submit auto-submit bot removed the autosubmit Merge PR when tree becomes green via auto submit App label May 1, 2025
Copy link
Contributor

auto-submit bot commented May 1, 2025

autosubmit label was removed for flutter/flutter/168082, because - The status or check suite Linux customer_testing has failed. Please fix the issues identified (or deflake) before re-applying this label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
engine flutter/engine repository. See also e: labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants