It seems that CircleShape works not so fast as it can

[mkalex777]

I looked in the code of CircleShape and it seems that it uses not so fast algorithm to calculate circle points.
Here is the code from SFML 2.3.2:

Vector2f CircleShape::getPoint(std::size_t index) const
{
    static const float pi = 3.141592654f;

    float angle = index * 2 * pi / m_pointCount - pi / 2;
    float x = std::cos(angle) * m_radius;
    float y = std::sin(angle) * m_radius;

    return Vector2f(m_radius + x, m_radius + y);
}
 

here is a more fast algorithm:

private void DrawCircle(RenderWindow window, Vector2f pos, float radius, Color color)
{
    var list = new List<Vertex>();

    const int numSegments = 50;
    var theta = 2F * (float)Math.PI / numSegments;
    var s = (float)Math.Sin(theta);    //precalculate the sine and cosine
    var c = (float)Math.Cos(theta);
    var vector0 = new Vector2f(radius, 0F);  //we start at angle = 0
    for (var i = 0; i < numSegments; i++)
    {
        //apply the rotation matrix
        var vector1 = new Vector2f(c * vector0.X - s * vector0.Y, s * vector0.X + c * vector0.Y);
        list.Add(new Vertex(pos + vector0, color));
        list.Add(new Vertex(pos + vector1, color));
        vector0 = vector1;
    }

    window.Draw(list.ToArray(), PrimitiveType.Lines);
}
 

I taken this algorithm here: http://slabode.exofire.net/circle_draw.shtml
And it works just like a charm

[Laurent]

You realize that your code generates the circle in a single call, while SFML has to provide each point separately, right? Although this doesn't mean that it is impossible to precompute stuff like your code does, it makes it more "ugly" by adding members to the class and managing states that persist across the calls to getPoint.

So, please start by the beginning: do you have a use case where optimizing this specific function show significant benefit? Or are you just sharing random thoughts about SFML sources?

[mkalex777]

You realize that your code generates the circle in a single call, while SFML has to provide each point separately, right? Although this doesn't mean that it is impossible to precompute stuff like your code does, it makes it more "ugly" by adding members to the class and managing states that persist across the calls to getPoint.

So, please start by the beginning: do you have a use case where optimizing this specific function show significant benefit? Or are you just sharing random thoughts about SFML sources?

yes, current implementation spent too many time to calculate sin/cos for every point and to make several calls (each call requires preparing stack and resets CPU conveyor and depends on CPU branch predictor). So, it's the reason to redesign it to get much better performance.
It's just a snippet on how we can optimize it to get much better performance

[Laurent]

We usually don't optimize something that doesn't prove to be an issue. Clean/maintainable code is preferred.

So it's useless to continue this discussion unless you have a concrete example with profiling data that shows a real issue here.

[mkalex777]

We usually don't optimize something that doesn't prove to be an issue. Clean/maintainable code is preferred.

So it's useless to continue this discussion unless you have a concrete example with profiling data that shows a real issue here.

Ok, so I hope it will be useful for someone who needs fast circle rendering

[Laurent]

You know, point generation probably takes a tiny amount of resources compared to actual rendering of the circle, and it only happens when the circle definition changes, not 60 times per second... so I wouldn't label this optimization as "fast circle rendering".