[app_server] shifted images in ScreenSaver

[diver]

ScreenSaver pref have shifted images (crossed red circles), i've heard that is most probably a bug in app_server, so i'll switch comonent to it.

[axeld]

What do you mean by "shifted image"? Can you provide a screen shot?

[diver]

This is still reproduceble in both vmware and real hardware.

[mattlacey]

I think this may be related to sub pixel precision when drawing.. if I change kStopSize to 16.0 in ScreenCornerSelector.cpp (I was trying an even value to see if it was due to odd pixel counts), I get the two stop signs being drawn differently, one draws as before, the other correctly with the line central on the circle.

[axeld]

I get a mail for every change of this bug because it's assigned to me. I get a mail for every change of any bug, because I subscribed to the bug mailing list. I certainly don't need another mail as CC ;-)

So what's missing is obviously either enabling sub-pixel drawing for that view, or make sure that both stop signs start at a rounded position. I guess the former would be better suited, as it will make sure the sign looks always good, no matter how large it is.

[stippi]

Actually, it is an app_server bug though, since sub-pixel rendering is not supposed to have an effect, unless the BView has B_SUBPIXEL_PRECISE in it's flags. I fixed quite a few issues, but I know that triangles and BShapes in general don't snap to pixels. Might be more issues.

[mattlacey]

Heh, Sorry Axel :)

Stippi - is there anywhere that describes how the sub-pixel rendering works? I wwas quite suprised to see code that would adjust the points you passed into it. I'll have a more in depth look at it but any reference material would be welcome!

[axeld]

Subpixel-rendering just means that you can specify a subpixel as the target of a drawing operation.

But I can't see why this must be the issue Stippi mentioned here: if the figure snap to pixels, it can easily be that it looks like in the screenshot - they might be rounded differently, if they don't start at the same position.

[stippi]

The problem is two-fold. AGG works with sub-pixel coordinates. This simply means that the coordinate (5.0, 4.0) refers to the top left "corner" of the pixel at index (5, 4) in a bitmap buffer. It also refers to the bottom right "corner" of the pixel at index (4, 3). In BeOS terms, (5.0, 4.0) refers to the center of (5, 4).

Here is why the problem is two-fold: When drawing strokes, it helps to apply an offset to all coordinates. This is what app_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 when drawing 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-top coordinate is already at the correct position. However, the right-top and the bottom 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). The perfect results would be achieved by shifting all triangle coords by an offset of (0.5, 0.5) and then dilating the whole shape outward by (0.5, 0.5). Dilating can of course be quite a challenging operation. Fortunately, AGG comes with the suitable vector converter (agg::conv_contour). I don't know how expensive agg::conv_contour is in real life, maybe I should just adopt the code to use it for triangles and BShapes.

Note: I don't know if any of this applies to the bug at all, since for ellipses and strokes, I already _should_ have the code to handle them. Maybe there is just a problem in those code paths.

[diver]

Still here in hrev35569.

[diver]

Still reproducible in hrev38300.

[pulkomandy]

Fixed in hrev48055. The screensaver preflet was, I think incorrectly, ceiling the value used to stroke the line. In subpixel precise mode and without rounding, everything looks as it should.