[libGD] #79 [Comment added] arc's are drawn incorrectly (plus regression in 2.0.35RC2)

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#79 - arc's are drawn incorrectly (plus regression in 2.0.35RC2)
User who did this - Pierre Joye (Pierre)

----------
"This is what I used to generate test2.png. I see the same affect with arcs, but this demonstrates that lines are affected as well. When output to a PNG image, there are 2 problems:"

For clarity, there is only two buffer formats:

  * TrueColor 8 bits per channel and 7 bit for alpha, the color values are stored directly in the image
  * Palette image, 8 bits per channel and 7 bit for alpha, the color values are stored in a palette and only the index is stored in the image. Limited to 256 colors (bgd incl.)

Each of this format can be saved to an image file or stream. Internally each file format support both or only one image type. PNG supports both, GIF supports only palette based image (we have to use dithering for truecolor iamge), jpeg support only truecolor image.

"The lines are anti-aliased against the wrong background color. If you view the image over a white background, you will see that the lines were anti-aliased against black (instead of anti-aliased using alpha, such as text rendered by stringFT would be)."

That's yet another problem. We do not support AA based on the alpha channel like what we do in the StringFT functions. By the way, it does not happen with a white background but when the backroung is completely transparent (gdTrueColorAlpha(0,0,0,127) in your example).


"Angled lines are rendered differently than horizontal and vertical lines. In some conditions, you are are using the requested thickness and not anti-aliasing."

The start and end of each line are pixel aligned (no partial coverage). There is no AA for axis aligned lines as they fit exactly on the pixels they cover. For a non axis aligned line, the ideal line (with a thickness of 1) will cover more than one pixel, for example 80% at (10,10) and 20% at (10,11) is the position for the pixel at (10.0, 10.20).

"my suggestion would be to always disable anti-aliasing and use the requested thickness, when thickness >1 is requested. That would be the closest to the desired effect, and would make the image look more consistent across output formats."

It sadly cannot be done now as it will suddenly bring some backward compatibility problem. I suggest you to manually disable AA when you have a thickness > 1. Doing so will help you to implement a function compatible with 2.1.0 and earlier version as well.

To bring at least one good news, 2.1.0 may support floating start/end points. It will greatly improve the complex shapes rendering and positioning.

I would you like to thank you again for the detailed feedbacks. It confirms the choices we made for 2.1.0 and gave us a couple of good test cases!

I will close this bug as the initial issue is fixed and the other problems described here are already reported in other bug reports (AA, arcs and lines with thickness and alpha values).
----------

More information can be found at the following URL:
http://bugs.libgd.org/?do=details&task_id=79#comment253

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.