[haiku-development] Re: Disable BView antialiasing
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 23 Sep 2009 10:44:06 +0200
On 2009-09-23 at 10:11:33 [+0200], Caitlin Shaw <rogueeve@xxxxxxxxxxxxx>
wrote:
>
> > Regarding the topic of this thread, shouldn't there be a way to undo
> > the antialiased line with the right combination of colors and drawing
> > mode? In other words a sort of inverse antialias? If not maybe we could
> > add something like that, assuming it is possible.
> >
> >
> I'll bet you could, but that sounds like a hack to me. Maybe if it was
> integrated into the library it could become a "clever hack", but...I
> dunno, it feels fishy to me.
>
> >
> > It seems to me that the current situation is something of a mistake.
> > I'd bet mine isn't the only app that uses B_OP_INVERT and breaks! I'd
> > have thought that StrokeLine et al should behave like their BeOS
> > prototypes, and there should be StrokeAliasedLine etc, or such, for the
> > new behaviour.
> >
> >
> I actually hate to "diss" the anti-aliasing, because I can tell the
> painter library (AGG?) is very good and it really does look pretty. IMHO
> I do believe the above feels like the Right Way though. In addition to
> breaking older programs, forcing antialiasing has some other annoying
> side-effects:
>
> * For erasure, even if you do try to just redraw the affected area, it
> may not be clear exactly what that area is, because the aliasing "smears"
> out from the line you drew to some unknown-to-you distance, which leads
> you to have to put in a "fudge factor". And there are some situations
> where you can NOT easily redraw, for example in the old game "Snake" or
> "Light Cycles" there's really no good way to erase the end of your tail
> except by drawing over it, and you don't want to erase too much, or you
> might erase part of the other cycle or yourself. Redrawing the entire
> screen in a BBitmap and then blitting it over is needlessly inefficient,
> and in cases like the above, actually more difficult to figure the code
> for it.
Agreed.
> * There is a possibility the aliasing could smear across one section of
> the view into another, when the sections are supposed to be exclusive. I
> had this problem in my text editor, when the anti-aliasing from the "_"
> character--which is drawn on the very bottom pixel of the line--would
> smear down into the line below it, possibly leaving trails on the lower
> line, as the editor only redraws lines which have changed. This is
> obviously a _font_ antialiasing problem, but a similar situation could
> apply in other cases as well. See the above "light cycle" example: what
> if you get really close to the other player, and corrupt the color of
> part of his cycle?
Actually, both the aliased and anti-aliased drawing method alter the
affected geometrical region according to the pixel grid. Only the rounding
is different. For example, if you draw a one pixel wide line on (0.6,
0.0)-(0.6, 3.0), for aliased drawing, the second row of pixels will not be
affected, dispite the geometrical coverage of the line clearly affecting
those pixels. So you have to round every edge down to get the true
coverage. With anti-aliased drawing, you have to round up and down
(left/top -> round down, right/bottom -> round up). I don't see anything
wrong with it.
> * Purely horizontal or vertical lines are not antialiased, so if a line
> were spinning or something (e.g. I'm thinking, like, the Angle control in
> the Drop Shadow setup in Photoshop), the line would look thinner at
> 0, 90, 180, & 270 degrees than at other times.
This is incorrect. With aliased lines, you have the problem that 45° lines
appear thinner than straight lines (that's true because such a line has the
same number of pixels as a straight line of the same Y or X distance, yet
the line is longer). You can easily see this. One of the main features of
anti-aliasing is to elliminate precisely this effect, by always affecting
pixels according to the true geometrical coverage of a shape. If it doesn't
look correct, the problem is not the anti-aliasing, but the gamma
correction of the anti-aliasing coverage to alpha conversion.
> * Just hypothetically, there's a chance that a program that was trying
> to use color-keying, like if it was setting up sprites in an offscreen
> buffer or something, could cause itself problems when the antialiasing
> corrupts the color value around the image.
Correct, this problem would go away once this can be controlled via a view
flag.
> * The more you draw a line/shape (draw and then draw over), the thicker
> it gets, in sort of an airbrush effect. This just seems a little weird.
I consider this invalid. You are just not supposed to do that and it was
also a problem with BeOS back in the day. The same problems that applied
back then to text rendering, simply apply today to line rendering as well.
> I do NOT think the anti-aliasing should be gotten rid of, but I DO think
> it should be optional to the programmer. And we should think about
> whether it's a compatibility issue since there are at least two known
> apps that are broken by it. Current apps, being current, would
> theoretically be simple to add the line to turn it on. And old apps,
> well, they're old, it's hardly surprising if they look dated. I would
> also argue that "modern" does not necessarily == Vista-esque glitz, only
> the capability of supporting it. But again, I totally think the painter
> engine is a good thing, it looks great, it's just, I think it's got
> issues forcing these features onto every BView.
Ok, then we agree. :-)
Best regards,
-Stephan
Other related posts:
