Right now, arcs and circles (and maybe splines as well) are drawn with a relatively large chord tolerance, which often results in significant visual differences between the ideal arc and the polygon displayed.

They are drawn with the chord tolerance that you've specified in settings, which is as small as you set it.

However, drawing an arc with pixel accuracy is not something that should be particularly difficult, especially if it is parallel to the display plane (i.e., it's circular, not elliptical). So instead of drawing inaccurate chords, SolveSpace could detect when it could just draw an exact circle or arc, and then invoke the corresponding graphics primitive.

This doesn't make any sense. There is no graphical primitive for a circle or an arc in OpenGL, just triangles. Regardless of what you do, you have to choose some chord tolerance (perhaps corresponding to one pixel), and then convert a circle or an arc into piecewise linear representation.

and that, when switching to polygons is necessary, e.g., when tilting the plane, the transition may be unexpected, but I think all these issues are minor

I don't think these are minor issues. In particular, implementing this would require regeneration of the entire sketch, at least, every time you zoom in, and perhaps once you zoom out, to avoid having way too many edges. That is also a nontrivial computational cost.

The problem with setting a significantly smaller chord tolerance is that SolveSpace becomes extremely slow, probably since the chord tolerance also affects mesh operations. I guess having separate chord tolerances for arcs display and meshes could accomplish what I'm after.

Please let me be clear about the objective: the principal issue is that sloppily drawn geometry causes the designer to develop a sloppy mindset, which causes mistakes that could have been avoided. What I'm looking for is to remove the cause for that sloppiness, preferably without having to redesign the human condition at large :-) Now, I don't know the internal workings of SolveSpace nearly well enough to be able to tell how exactly this should be implemented. So I'm merely making suggestions based on things I'm familiar with.

Regarding primitives, I don't known OpenGL, but a quick search yielded https://www.opengl.org/discussion_boards/showthread.php/167955-drawing-a-smooth-circle mentioning gluDisk. https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluPartialDisk.xml looks useful. Is that prohibitively expensive ?

implementing this would require regeneration of the entire sketch

So the arc/polygon is precomputed and stored in OpenGL (I'm thinking "display lists" here. Not sure if that's still something people use.) ? If this is so (and the primitives are not issued for each screen refresh), perhaps arc/polygons could then be put in a separate display list, and you'd only regenerate that one when the zoom level changes. I'm assuming here that the expensive bit are mesh operations while the rest is fairly cheap.

Regarding primitives, I don't known OpenGL, but a quick search yielded https://www.opengl.org/discussion_boards/showthread.php/167955-drawing-a-smooth-circle mentioning gluDisk. https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluPartialDisk.xml looks useful. Is that prohibitively expensive ?

That's only useful in immediate mode, not when drawing in OpenGL 2.

So the arc/polygon is precomputed and stored in OpenGL (I'm thinking "display lists" here. Not sure if that's still something people use.) ?

More or less. Display lists specifically are useless but we have a similar data structure.

If this is so (and the primitives are not issued for each screen refresh), perhaps arc/polygons could then be put in a separate display list, and you'd only regenerate that one when the zoom level changes. I'm assuming here that the expensive bit are mesh operations while the rest is fairly cheap.

Yes. But the issue is that regenerating edges alone can be costly too.

@whitequark, @wpwrak We can easily make perfect primitives just using bezier representation and geometry shaders https://www.khronos.org/opengl/wiki/Geometry_Shader. But this require OpenGL 3.2.

I don't think OpenGL 3.2 is an option.

Why is OpenGL 3+ not an option?

We already require 3+, the problem was with 3.2 specifically. But now that I think about it again, we can gracefully degrade on pre-3.2 OpenGL to the current rendering, and use a much nicer one when geometry shaders are available.

This is a duplicate of #295 (exactly 100 higher, heh) and the correct solution (or at least realistically implementable one) is described in #295 (comment), so I'm closing this in favor of that issue.