Exactly Niko, and this problem is probably only solved by super- sampling in some form. Perhaps we should reinvestigate opengl rendering or something? Another strategy that could work is to note where all the edge pixels are in the destination (rather than computing blend, write a special colour or add to a separate bit plane) and rerender them at say 16x16.
njh
On Mon, Sep 22, 2014 at 10:27:15PM +0200, Niko Kiirala wrote:
Mon, 22 Sep 2014 10:00:14 -0700 Fabien Sanglard <fabiensanglard.net@...400...> kirjoitti:
It's an aliasing issue.
I thought it was a floating point accuracy issue ? Can you elaborate on this so I can understand the issue better ?
It is an issue of antialiasing combined with simple blending model.
Consider a pixel that is exactly divided in half by two polygon: polygon A fills the left side of the pixel, polygon B the right side.
Antialiasing tells us that each polygon on its own has a coverage of 0.5 (or 50 %) in that pixel. This far everything is correct.
Inkscape then uses simple alpha blending to combine the colour contribution from those two polygons to create the pixel colour. The blending stage does not know the shape of the two polygons, just that each would fill half of the pixel on its own.
The blending equations make the assumption that the two polygons are orthogonal to each other (say, A filling the left half and B filling the top half), which usually works well, but is bad in this exact corner case. So, the final coverage of the pixel becomes coverage(A)+coverage(B)*(1-coverage(a)) = 0.5 + 0.5*0.5 = 0.75.
So, instead of getting fully opaque pixel, we get 25 % transparent one. Rendered on top of white background, the pixel becomes considerably lighter than it should have been.