The problem is two-fold. AGG works withsub-pixel coordinates. This simply means that the coordinate (5.0, 4.0) refers tothe top left "corner" of the pixel at index (5, 4) in a bitmapbuffer. It also refers to the bottom right "corner" of the pixel atindex (4, 3). In BeOS terms, (5.0, 4.0) refers to the center of (5, 4).
Here is why the problem is two-fold: Whendrawing strokes, it helps to apply an offset to all coordinates. This is whatapp_server is already doing, unless the view flags specify B_SUBPIXEL_PRECISE.This flag existed on BeOS already, and seems to be meant to do the same thing,but produces graphics glitches.
The other part of the problem is whendrawing filled shapes: Imaging drawing a triangle on (5.0, 4.0 - 10.0, 4.0 -7.0, 8.0). In order to produce the same visual results as BeOS, the left-topcoordinate is already at the correct position. However, the right-top and thebottom coordinate need to be adjusted. The right-top should become (11.0, 4.0)(note how Y stays the same) and the bottom one should be (7.5, 9.0). Theperfect results would be achieved by shifting all triangle coords by an offsetof (0.5, 0.5) and then dilating the whole shape outward by (0.5, 0.5). Dilatingcan of course be quite a challenging operation. Fortunately, AGG comes with thesuitable vector converter (agg::conv_contour). I don't know how expensiveagg::conv_contour is in real life, maybe I should just adopt the code to use itfor triangles and BShapes.
Note: I don't know if any of this appliesto the bug at all, since for ellipses and strokes, I already _should_ have thecode to handle them. Maybe there is just a problem in those code paths.
Subpixel-rendering just means that you canspecify a subpixel as the target of a drawing operation.
But I can't see why this must be the issueStippi mentioned here: if the figure snap to pixels, it can easily be that itlooks like in the screenshot - they might be rounded differently, if they don'tstart at the same position.
Stippi - is there anywhere that describeshow the sub-pixel rendering works? I wwas quite suprised to see code that wouldadjust the points you passed into it. I'll have a more in depth look at it butany reference material would be welcome!
Actually, it is an app_server bug though,since sub-pixel rendering is not supposed to have an effect, unless the BViewhas B_SUBPIXEL_PRECISE in it's flags. I fixed quite a few issues, but I knowthat triangles and BShapes in general don't snap to pixels. Might be moreissues.
I think this may be related to sub pixelprecision when drawing.. if I change kStopSize to 16.0 inScreenCornerSelector.cpp (I was trying an even value to see if it was due toodd pixel counts), I get the two stop signs being drawn differently, one drawsas before, the other correctly with the line central on the circle.