Does the gdispDraw functions have AA ?

[kevin shang]

As the title , does the gdispDraw functions have antialias ?

[Joel Bodenmann]

Hello Kevin,

No, we currently don't have built-in anti-aliasing for shape rendering. The goal is to offer that as a 2nd set of functions. If you'd be interested in helping to implement those we'd highly appreciate it.

Anti-aliasing for font rendering is fully implemented though.

[inmarket]

As an aside: Antialiasing is an interesting problem. It requires the ability to know what the background is so that colors can be mixed. There are 2 ways to do this; "know" the background color eg gdispFillString, or read the background back from the display. Option 1 is limited to particular functions with filled backgrounds and option 2 is limited to displays that have that capability (definitely not even the majority of displays supported by uGFX). Also reading back from the display surface is often VERY slow even when it is possible. This then limits the usefulness of generic antialiasing in an embedded environment and is the major reason we have not invested the time into implementing it for anything other than fonts.

On a small display antialiasing also can make everything extremely "blurry". A much better approach for small displays is subpixel optimisation and is probably far more interesting for implementation for embedded purposes but it has higher computational requirements and the same read issues as antialiasing. 

Another issue with antialiasing is that drawing the same object twice in the same location leads to different displayed results (except in the case of a known background color). The reason is that the antialias weights on the 2nd draw get mixed with the antialias weights from the first draw. This then requires careful placement of draw order in order to ensure that things only get drawn once and the pixel areas affected by 2 antialiased operations don't affect each others antialiased results. This draw management adds complexity and computation resource requirements to the engine - usually more than would be suitable for an embedded environment. 

So, the conclusion of the above is that general antialiased drawing is not at all simple. While simplifications can be made it is still complex and would not be available for many drawing operations or on many types of hardware. Antialiasing is also not the best strategy for small lcd/oled displays with subpixel optimisation having significant advantages.

All the above lead to antialiasing on general drawing not currently being worth the time when there are so many other areas we can improve uGFX first.

[Joel Bodenmann]

7 hours ago, inmarket said:

Option 1 is limited to particular functions with filled backgrounds and option 2 is limited to displays that have that capability (definitely not even the majority of displays supported by uGFX).

Just for clarification for people that come around this post: This is not because µGFX doesn't support pixel read-back or doesn't support it well. It's just that, as @inmarket explained, it's often not supported by the hardware itself. µGFX has everything required to read back pixel values.

 

7 hours ago, inmarket said:

All the above lead to antialiasing on general drawing not currently being worth the time when there are so many other areas we can improve uGFX first.

That's correct, I fully agree. But that's also the reason why it would be awesome if somebody else would pick up this task