Opened 12 years ago

Closed 4 years ago

#1315 closed bug (fixed)

[app_server] shifted images in ScreenSaver

Reported by: diver Owned by: axeld
Priority: normal Milestone: R1
Component: Servers/app_server Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


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.

Attachments (1)

screensaver.png (12.0 KB) - added by diver 11 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 11 years ago by axeld

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

Changed 11 years ago by diver

Attachment: screensaver.png added

comment:2 Changed 11 years ago by diver

This is still reproduceble in both vmware and real hardware.

comment:3 Changed 11 years ago by mattlacey

Cc: axeld added

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.

comment:4 Changed 11 years ago by axeld

Cc: axeld removed

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.

comment:5 Changed 11 years ago by 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.

comment:6 Changed 11 years ago by 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!

comment:7 Changed 11 years ago by 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.

comment:8 Changed 11 years ago by 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.

comment:9 Changed 11 years ago by diver

Summary: [ScreenSaver] shifted images[app_server] shifted images in ScreenSaver

comment:10 Changed 9 years ago by diver

Still here in hrev35569.

comment:11 Changed 9 years ago by diver

Version: R1/pre-alpha1R1/Development

comment:12 Changed 9 years ago by diver

Still reproducible in hrev38300.

comment:13 Changed 4 years ago by pulkomandy

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.