Bounding boxes for Arc and Sector #698
Conversation
|
@jamwaffles I think I've got something for the Arc bounding box. I also try to copy / migrate what you did in #441 and #524. |
There was a problem hiding this comment.
I'm by no means an expert on the arc/sector code, nor the algorithms behind it, so I've asked @rfuest to give it a check over. Superficially, to me it looks quite clean but my gut tells me there are some optimisations to be made somewhere.
It also looks like there are some regressions in the tests - please check the CI output or cargo test locally if you can't get into CircleCI.
src/primitives/arc/mod.rs
Outdated
| let center = self.center(); | ||
| let radius = self.radius(); |
There was a problem hiding this comment.
To get accurate results you'll need to use Circle::center_2x instead of center and scale all coordinates by 2. center does round the center point to the nearest integer, which isn't accurate for circles/arcs with even diameters. The radius in the scaled up coordinate system is then equal to diameter.
There was a problem hiding this comment.
I feel like dividing the returned Point by 2 will have the same effect, isn't it?
There was a problem hiding this comment.
Which Point do you mean? The result of point_from_angle?
There was a problem hiding this comment.
Yes. I feel I could avoid to work with the radius on the bounding_box function and simply reuse top_left + diameter, etc.
There was a problem hiding this comment.
I'm still not sure I understand what you mean. But you could get rid of using Real for the radius function by scaling the coordinate system up by a factor of 2.
There was a problem hiding this comment.
Not easy sweat_smile
No it's not, the half pixel offset that creeps into many calculations can get really confusing.
The BB isn't correct for some negative start angles:
There was a problem hiding this comment.
Negative sweep angles are also broken:
There was a problem hiding this comment.
Oh, completely forgot to test the negatives angles 😅
But I've seen that I forgot to normalize the angles during the refactoring, which is probably why it's broken. (hopefully)
There was a problem hiding this comment.
Ok, I fixed it by using the PlaneSector that @jamwaffles introduced on the other PR. Although it's not always pixel perfect.
With the debug tools, the stroke size pushes the bounding box in a weird way. Shouldn't it stay the same, disregarding the stroke width?
There was a problem hiding this comment.
Ok, I fixed it by using the PlaneSector that @jamwaffles introduced on the other PR. Although it's not always pixel perfect.
Getting a pixel perfect result will be hard to achieve. If it isn't possible to implement this in a reasonable way we should at least try to make sure that the bounding box will never be smaller than the content. IMO an additional row or column of empty pixels inside the BB is less of an issue than pixels outside the BB, which would get clipped or overlap other drawn elements.
With the debug tools, the stroke size pushes the bounding box in a weird way. Shouldn't it stay the same, disregarding the stroke width?
There are two different bounding boxes: Arc::bounding_box and Styled<Arc, PrimitveStyle<C>>::bounding_box. The unstyled BB is constant, but the styled bounding box must include the stroke width and stroke alignment.
|
I only did take a quick look at the code, but the general concept looks good. If you haven't already noticed it I would also like to point you to the |
It's because of the bounding box usage for the dimension test for instance. I fixed them by simply using the circle conversion and add other tests for the bounding box. |
|
I have the feeling that the stroke for Sector is wrong at the center. It looks twice as large as what I think it should be. |
|
I think it is correct, or at least the way it was designed to work. The two line segments should be drawn the same way as a |
|
But something definitely isn't right with some edge cases. I'll add some of my findings to #484. |
|
I quickly checked how Sketch or Affinity Designer behave with polygones and large strokes. Well, it's bad too with narrow angles :-/ Definitely not an easy topic. Now I am wondering if it wouldn't be better to offer only rounded corners instead, because it has the advantage to be consistant with every angle values. (For Sector and polygones at least) Not sure it's easier to implement though ^_^ |
Thank you for helping out with embedded-graphics development! Please:
CHANGELOG.mdentry in the Unreleased section under the appropriate heading (Added, Fixed, etc) if your changes affect the public APIrustfmton the projectjust build(Linux/macOS only) and make sure it passes. If you use Windows, check that CI passes once you've opened the PR.PR description
Fix #405 Bounding boxes for Arc and Sector don't take the angles into account.