Skip to content
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

Arc angle starting position is unusual #909

Open
tgross35 opened this issue Jun 6, 2024 · 2 comments
Open

Arc angle starting position is unusual #909

tgross35 opened this issue Jun 6, 2024 · 2 comments

Comments

@tgross35
Copy link
Contributor

tgross35 commented Jun 6, 2024

I am trying the following code:

let mut builder = Path::builder().with_svg();

builder.arc(
    lyon::math::point(1000.0, 1000.0),
    vector(500000.0, 500000.0),
    Angle::radians(std::f32::consts::PI * 3.0 / 2.0),
    Angle::radians(0.0),
);

let path = builder.build();

self.stroke_tess
    .tessellate_path(
        &path,
        &STROKE_OPTIONS
            .with_line_width(10000.0)
            .with_start_cap(lyon::path::LineCap::Square)
            .with_end_cap(lyon::path::LineCap::Round),
        &mut BuffersBuilder::new(
            &mut self.stroke_geometry,
            WithColor(item.color.as_float_rgba()),
        ),
    )
    .unwrap();

And it comes up with this result:

image

From this, it looks like the angle starts at -3π/4 and the angle increases counterclockwise. This seems weird to me instead of starting at 0 - is this correct?

@nical
Copy link
Owner

nical commented Jun 8, 2024

The reason the arc is angled this way in your example is that the original angle is defined by the angle between the center and the current position of the path builder. If there hasn't been any command in the path builder, the current position is (0, 0). If you try to use a move_to command before the arc it should affect the starting angle accordingly.

@nical
Copy link
Owner

nical commented Jun 8, 2024

I explained why arc is the way it is in lyon, I also think that this behavior is fine but that doesn't necessarily mean that it should be that way. I don't have the time right now to delve into the SVG specification and figure out whether another behavior for this special case would better match the spec, but feel free to make a case for it if you think that's the case.

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

No branches or pull requests

2 participants