PDF Generating Tool Support Forum

HOME   Login   Register    Search

  Subject: Antialiasing and getPixel
   PostPosted: 04 Mar 2017, 13:37 
I am mainly interested in the antialiasing capabilities of the Pixels library. I can run the "PixelsTest" successfully on an Arduino Mega or Due with a 320x240 SainSmart TFT, but especially antialiased lines look somehow poor because the brightness fluctuates over the length (see attached photos).
As far as I know proper antialiasing is only possible if video RAM read is supported. Therefore I have modified the shield so that the RD pin of the LCD controller can be controlled by Digital Pin #42 of the Arduino.
I have also added this pin in the SSD1289.h file:
        setPpiPins(38, 39, 40, 41, 42); // dummy code in SPI case

Unfortunately this had no effect at all. I have found that the pixel color is handled in the putColor function:
void PixelsBase::putColor(int16_t x, int16_t y, boolean steep, double alpha) {
    RGB* result;
    if ( alpha != 1 ) {
        [color=#FF0000]RGB* bg = getPixel(x, y);[/color]
        result = computeColor(bg, alpha);
        RGB* sav = getColor();
        drawPixel(x, y);
    } else ...

There is only one definition of getPixel(..) which only returns the background color and doesn't read the video RAM at all:
RGB* PixelsBase::getPixel(int16_t x, int16_t y) {
    return getBackground();

So it is not really a surprise that antialiasing doesn't work as it should.
Unfortunately I have not yet figured out what I have to add in the driver to read the pixel color.
Any help is appreciated.


File comment: Anitaliased mesh with irregular brightness.
MeshAA.JPG [ 88.09 KiB | Viewed 2209 times ]
File comment: Anti-Aliased Round Rect with dark corners.
RoundRectAA.JPG [ 43.04 KiB | Viewed 2203 times ]
  Subject: Re: Antialiasing and getPixel
   PostPosted: 06 Mar 2017, 16:39 
> As far as I know proper antialiasing is only possible if video RAM read is supported.

It is only critical if you draw antialiased primitives or text over an image or over a background, whose color changes. If the background color is constant, it is sufficient just to call setBackground() with the matching value in advance to an antialiased graphics or text output.

You are right, getPixel() does not work as planned yet. It is mostly because the function is hw-supported by TTF modules rather as an exception (only by few modules from dozens we have here). Another point is a performance impact. For classical low-end Arduinos the extra IO operations and caused slowdown may be unacceptable. That does not mean the method is not going to be properly implemented - it just has a lower priority for the time being.

The "brightness fluctuates" issue can be resolved by fine tuning of TFT module gamma. Unfortunately the needed methods are also "under construction".

Also I do not exclude a value rounding bug in
void PixelsAntialiased::drawLineAntialiased(int16_t x1, int16_t y1, int16_t x2, int16_t y2);
I'll address the issue this week. You could also play with the method implementation - it is simple and there is a variety of alternative implementations available in the Internet.

[Reply]     [ 2 posts ] 

Copyright ©2004-10 zefer|org. All rights reserved. Bookmark and Share