Skip to content

Conversation

@LaurenzV
Copy link
Contributor

A revival from an older PR. Confirmed to give a decent speed boost for 8x8 and 16x16 shapes.

@LaurenzV LaurenzV requested a review from tomcur September 14, 2025 10:01
@tomcur
Copy link
Member

tomcur commented Sep 14, 2025

I've suggested two tighter (and cheaper to compute) bounds that I believe to be correct.

Copy link
Member

@tomcur tomcur left a comment

Choose a reason for hiding this comment

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

Happy to merge this and open the further improvements as a separate PR, perhaps having more eyes on that math would be good.

@LaurenzV
Copy link
Contributor Author

Nice! Yes I also figured that there probably is a way to generate an even tighter bbox, but lacked the maths skills to figure it out. 😄

@LaurenzV
Copy link
Contributor Author

Really impressive, this gives yet another pretty significant speed boost on top of what was initially introduced in this PR!

@LaurenzV
Copy link
Contributor Author

Here's the comparison to main now:

image image image

@LaurenzV LaurenzV added this pull request to the merge queue Sep 14, 2025
Merged via the queue into main with commit aade1a9 Sep 14, 2025
17 checks passed
@LaurenzV LaurenzV deleted the laurenz/small_curve_opt branch September 14, 2025 15:38
@tomcur
Copy link
Member

tomcur commented Sep 14, 2025

Not bad at all!

tomcur added a commit to tomcur/kurbo that referenced this pull request Sep 14, 2025
This is a branchless calculation of a point-onto-line-segment
projection. Also marks the method `#[inline]`.

I started looking at this because of the math we introduced in
linebender/vello#1214. This might allow us to
introduce some tighter bounds there without introducing additional
branching.

This should be useful here regardless of whether the above happens.
@tomcur
Copy link
Member

tomcur commented Sep 14, 2025

I've opened linebender/kurbo#505, which may allow us to introduce tighter bounds.

The idea would be to test whether the control points are very close to their projection onto the chord/line segment defined by the Bezier end points, rather than just close to the end points.

Edit: see #1216.

tomcur added a commit to tomcur/kurbo that referenced this pull request Sep 19, 2025
This is a branchless calculation of a point-onto-line-segment
projection. Also marks the method `#[inline]`.

I started looking at this because of the math we introduced in
linebender/vello#1214. This might allow us to
introduce some tighter bounds there without introducing additional
branching.

This should be useful here regardless of whether the above happens.
github-merge-queue bot pushed a commit to linebender/kurbo that referenced this pull request Sep 19, 2025
This is a branchless calculation of a point-onto-line-segment
projection. Also marks the method `#[inline]` and adds some testing.

I started looking at this because of the math we introduced in
linebender/vello#1214. This might allow us to
introduce some tighter bounds there without introducing additional
branching.

This should be useful here regardless of whether the above happens.

---------

Co-authored-by: jneem <[email protected]>
flaviotore added a commit to flaviotore/kurbo that referenced this pull request Oct 9, 2025
This is a branchless calculation of a point-onto-line-segment
projection. Also marks the method `#[inline]` and adds some testing.

I started looking at this because of the math we introduced in
linebender/vello#1214. This might allow us to
introduce some tighter bounds there without introducing additional
branching.

This should be useful here regardless of whether the above happens.

---------

Co-authored-by: jneem <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants