Skip to content

Ubersdfalwaysfilledrectgeometry#184748

Draft
flar wants to merge 8 commits intoflutter:masterfrom
flar:ubersdfalwaysfilledrectgeometry
Draft

Ubersdfalwaysfilledrectgeometry#184748
flar wants to merge 8 commits intoflutter:masterfrom
flar:ubersdfalwaysfilledrectgeometry

Conversation

@flar
Copy link
Copy Markdown
Contributor

@flar flar commented Apr 8, 2026

A proposal to simplify UberSDFGeometry.

@github-actions github-actions Bot added engine flutter/engine related. See also e: labels. e: impeller Impeller rendering backend issues and features requests labels Apr 8, 2026
Comment thread engine/src/flutter/impeller/entity/geometry/uber_sdf_geometry.cc
Comment on lines +17 to +18
Rect bounds = Rect::MakeOriginSize(params_.center,
Size(params_.size.x, params_.size.y));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think currently this is just the positive quadrant of the bounds, rather than the full bounds. For the full bounds, should origin be center - size, and size be params.size * 2?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Ooops, you're right. D'oh! Or add *2 to the constructed Size object here.

Also, this points out that by storing these "size" values as Points we are fighting our CPU code a bit, but the values in the FragInfo have to be GPU types which are vec2/Point.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I was thinking it was CenterSize, but double D'oh!

if (!transform.IsTranslationScaleOnly()) {
return false;
}
return GetExpandedDeviceBounds(transform, true).Contains(rect);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do we really need to inset by AA here?

I think the regular base bounds would be considered fully inside the coverage area. I think AA padding doesn't shrink the coverage area in any way. So we can just use the transformed base bounds, and wouldn't need to account for AA here. Is that correct, or am I misunderstanding something?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Never mind. Thinking about it some more, I see how the AA is smudging the edge of the base bounds in both the positive and negative direction. I think you're correct here.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

And the things it covers are smudging their output by the AA fringe as well. This could get ugly if there are cases where we look for coverage for precise boundaries. I'd have to look at how this method is used (and its doc comments could be more explicit about a lot of this).

transform.GetMaxBasisLengthXY());
}

GeometryResult UberSDFGeometry::GetPositionBuffer(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

So GetPositionBuffer returns results in local (untransformed) space. And GetCoverage/CoversArea works in device (transformed) space. I think this is not very obvious, and should be explicitly stated in geometry.h.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I agree!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I only learned this by looking at other implementations...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

e: impeller Impeller rendering backend issues and features requests engine flutter/engine related. See also e: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants