Request: use dynamic values for number of vertices etc.

The samples use 22 as the number of vertices for a curve/circle. If you draw a large circle, it ends up looking quite rough. So in one of my samples I set it to 100... but then not all the points can be rendered because there are too many.

The sample I'm talking about is just a clock, so there's a big outer circle and a bunch of smaller 'dots' as minute/hour indicators, as well as the clock hands.

Yes, probably it would be better to render a bitmap and blit it but that's not what the sample is about.

I would like to suggest that instead of using a hard-coded value for the number of vertices, perhaps it would be better to use a "maximum number of pixels" for the length of each segment. So that when drawing a circle, the number of vertices used would increase as the radius did, to maintain a level of smoothness uniformly without overtaxing memory.

Open to other suggestions...

Start by locating the samples that hard-code 22 vertices for curves and circles, including the clock sample described in the issue. Read the relevant drawing and vertex-limit code to understand how larger circles currently exceed the available points. Done means an agreed dynamic sizing approach is implemented without overtaxing memory and the affected samples render smoothly.

Written by the indexing model from the issue text.