Anti-aliased arc in 'Sprite-only' display buffer mode...

[nikthefix]

Only raise issues for problems with the library and/or provided examples. Post questions, comments and useful tips etc in the "Discussions" section.

To minimise effort to resolve issues the following should be provided as a minimum:

1. A description of the problem and the conditions that cause it to occur
2. IDE (e.g. Arduino or PlatformIO)
3. TFT_eSPI library version (try the latest, the problem may have been resolved!) from the Manage Libraries... menu
4. Board package version (e.g. 2.0.3) available from the Boards Manager... menu
5. Procesor, e.g RP2040, ESP32 S3 etc
6. TFT driver (e.g. ILI9341), a link to the vendors product web page is useful too.
7. Interface type (SPI or parallel)

Plus further information as appropriate to the problem:

1. TFT to processor connections used
2. A zip file containing your setup file (just drag and drop in message window - do not paste in long files!)
3. A zip file containing a simple and complete example sketch that demonstrates the problem but needs no special hardware sensors or libraries.
4. Screen shot pictures showing the problem (just drag and drop in message window)

The idea is to provide sufficient information so I can setup the exact same (or sufficiently similar) scenario to investigate and resolve the issue without having a tedious ping-pong of Q&A.

DO NOT paste code directly into the issue. To correctly format code put three ticks ( ` character on key next to "1" key) at the start and end of short pasted code segments to avoid format/markup anomolies. See here:

Example output:

  Serial.begin(115200);
  tft.init();

[nikthefix]

Hi Bodmer, I have for a long time been using TFT_eSPI with a sprite-only 'frame buffer' to push to arbitrary display drivers. It works great!

I recently tried the SmoothArc anti-aliased draw and found that my display architecture was such that the physical RGB sub-pixel arrangement compromised the effect as the added sub-pixels were 'from the wrong end' so to speak.

Obviously there's no way for TFT_eSPI to know about my pixel layout when working in this way but I wonder, is there an easy way in the lib to specify the RGB ordering of just the anti-aliasing algorithm?

A logical 180 degree rotate in my display driver solves it but this is not practical for my application.

Horizontal AA is enough for what I'm trying to achieve.

Any advice would be most welcome.

Thanks,

nik

[flykarlos]

I have exactly the same problem. When using rotated sprite as framebuffer for third party display drivers everything what should be antialiased is distorted

[nikthefix]

@flykarlos

I think this is a problem with the sub-pixel rendering approach in general since the AA algorithm needs to be pixel layout aware for each possible rotation. For 180 degree flips it should be possible to mod the algorithm but for 90 degree rotates I'm not sure how you'd go about it. I've been looking for an alternative AA approach but so far my best solution is to use a higher pixel density display without AA.

nik