Closed Arc Fill

[chrisjn52]

Are there any plans to create a function that fills two concentric arcs as shown below?

I have tried using a gdispFillArc() and overwriting with a circle in the background colour which is fine for a static shape but too slow for any dynamic display.

Would a variant of the gdispFillArc() function be the best way forward?   

[inmarket]

Arc filling is exceptionally complex. If you have a look at the code you will see it is by far the largest drawing function in gdisp. While there are some closed source implementations, uGFX is the only implementation that I know of where the source code is published (I know as I wrote the arc fill routine).

To add a concentric circle arc routine as in your image multiplies the number of possible segment cases by about four times and that is without taking into account corner cases.

So to answer your question, there are no plans to add such a routine. It is just too hard when the same thing can be achieved  (although slower) with two seperate simpler arc draws.

The only way we would consider adding such a routine would be if a commercial customer was prepared to pay to have it added.

[chrisjn52]

Duh, I've missed a simple solution, rotate small polygon segments about the axis of a circle such that they form a continuous arc! The narrower the polygon, the more accurate the arc formation. This should still be much faster than the hardware is capable of filling all the pixels of a much larger circle in order to overwrite most of the the gdispFillArc() segments. 

   

[Joel Bodenmann]

Depending on the platform, that might actually be slower.

If you have the RAM to spare you might want to consider rendering into a pixmap and then blitting the finished pixmap on the display instead. But again, it depends on the system whether that would actually be faster. For example, on an STM32 using the LTDC that might actually be slower depending on where the pixmap will be located in (eg. if it's in the same memory as the framebuffer then you would slow things down compared to simply drawing multiple times over the same framebuffer).

[chrisjn52]

I can appreciate how this would speed things up but I have very limited RAM in the STM32F103 so pixmaps of any appreciable size are not feasible.

I am not familiar with all the variations in hardware capability of each microcontroller and TFT driver chips but I don't believe I have any other options for faster drawing on the STM32F103 and a ILI9341 controller that I am using, but please correct me if I am wrong.

I am attempting to write a dial/meter widget much like this, which requires dynamic display of the segments that require updating. Whilst my original simple approach worked, it suffered from display artifacts due to the time delay in overwriting part of the arcs with the circle, (only for increasing meter vales).