The correct name would be "aliaslines". anti-aliasing is when you use shades of gray to approximate pixels that do not fall on the pixel grid. What we are doing here is defeating the built-in anti-aliasing by making sure all of our pixels are aligned with the grid.
I guess using +0.5 may actually do the right thing anyways. Who knows how the browser decides to round fractional positions to pixels? Maybe it does the right thing. SWF seems to call this feature gridFit? Is that really all we are talking about, that SWF has a default setting for gridFit that is different than the default for DHTML? I can see arguments in either direction: do you want your lines to be drawn where you asked them to be (which may require anti-aliasing) or do you want them to be aligned to the pixel grid so there is not any anti-aliasing? On 2010-03-05, at 16:36, Max Carlson wrote: > I think antialiaslines is a better attribute name - we can change that. > > I tried offsetting x/y a number of ways and only got good results by > always offsetting by +.5 x/y method -.5 didn't look good. > > It needs to be somewhat predictable - turning the option on does change > the paths you want to draw a little bit, e.g. with the current scheme > you can't draw right up to the width/height without lines getting clipped. > > I agree with the sentiment of moving 1/2 of the pixels in each direction > based on even/odd but it's not straightforward, and I'd be worried about > lines ending up crooked and shapes not ending up consistently scaled. > > BTW, it's kind of ridiculous this isn't built-in to the HTML5 canvas > (like it is in Flash) but there you have it! > > Regards, > Max Carlson > OpenLaszlo.org > > On 3/5/10 12:05 PM, P T Withington wrote: >> Well to my non-graphics-designer eye, the example looks fine. I suspect the >> higher the resolution of your display, the less this is an issue. >> >> If we are going to jitter any odd-width line by 1/2 a pixel to make them >> "crisp" (isn't this just anti-anti-aliasing?) then it seems to me we >> shouldn't _always_ shift in the same direction, that we should try >> statistically to move 1/2 of the pixels in each direction, so for instance >> base the rounding on the odd/even-ness of the position? >> >> On 2010-03-05, at 14:46, Max Carlson wrote: >> >>> The first line in your example looks 50% gray instead of black! Sadly, >>> no - the canvas implementation doesn't take care of this. More details >>> here: >>> https://developer.mozilla.org/en/Canvas_tutorial/Applying_styles_and_colors#A_lineWidth_example >>> >>>> Obtaining crisp lines requires understanding how paths are stroked. In the >>>> images below, the grid represents the canvas coordinate grid. The squares >>>> between gridlines are actual on-screen pixels. In the first grid image >>>> below, a rectangle from (2,1) to (5,5) is filled. The entire area between >>>> them (light red) falls on pixel boundaries, so the resulting filled >>>> rectangle will have crisp edges. >>>> >>>> If you consider a path from (3,1) to (3,5) with a line thickness of 1.0, >>>> you end up with the situation in the second image. The actual area to be >>>> filled (dark blue) only extends halfway into the pixels on either side of >>>> the path. An approximation of this has to be rendered, which means that >>>> those pixels being only partially shaded, and results in the entire area >>>> (the light blue and dark blue) being filled in with a color only half as >>>> dark as the actual stroke color. This is what happens with the 1.0 width >>>> line in the previous example code. >>>> >>>> To fix this, you have to be very precise in your path creation. Knowing >>>> that a 1.0 width line will extend half a unit to either side of the path, >>>> creating the path from (3.5,1) to (3.5,5) results in the situation in the >>>> third image -- the 1.0 line width ends up completely and precisely filling >>>> a single pixel vertical line. >>>> >>>> For even-width lines, each half ends up being an integer amount of pixels, >>>> so you want a path that is between pixels (that is, (3,1) to (3,5)), >>>> instead of down the middle of pixels. Also, be aware that in our vertical >>>> line example, the Y position still referenced an integer gridline position >>>> -- if it hadn't, we would see pixels with half coverage at the endpoints. >>> >>> >>> Regards, >>> Max Carlson >>> OpenLaszlo.org >>> >>> On 3/5/10 7:16 AM, P T Withington wrote: >>>> I don't understand this change. Shouldn't the browser canvas >>>> implementation be taking care of this? >>>> >>>> When I look at: >>>> >>>> >>>> https://developer.mozilla.org/samples/canvas-tutorial/4_5_canvas_linewidth.html >>>> >>>> which is drawing lines of even/odd width, the lines seem fine to me. >>>> >>>> On 2010-03-04, at 16:57, Max Carlson wrote: >>>> >>>>> Change 20100219-maxcarlson-3 by maxcarl...@bank on 2010-02-19 11:36:30 PST >>>>> in /Users/maxcarlson/openlaszlo/trunk-clean >>>>> for http://svn.openlaszlo.org/openlaszlo/trunk >>>>> >>>>> Summary: UPDATED: Add crisplines attribute to drawview >>>>> >>>>> Bugs Fixed: LPP-8780 - Strokes don't appear crisp in dhtml drawviews >>>>> >>>>> Technical Reviewer: ptw >>>>> QA Reviewer: hminsky >>>>> >>>>> Documentation: Updated to reflect recent changes in __playPath(). >>>>> Otherwise the same: >>>>> >>>>> Drawview now has a 'crisplines' attribute which if true causes lines to >>>>> be offset as needed to appear antialiased. This is only used in DHTML. >>>>> >>>>> Details: Add crisplines attribute. If true and lineWidth is an odd >>>>> number, offset all positions by .5 to cause lines to appear antialiased. >>>>> >>>>> Tests: See test/drawing/drawing.lzx?lzr=dhtml&lzt=html. Try changing the >>>>> crisplines attribute to false and see the black box's borders become >>>>> blurry. >>>>> >>>>> Files: >>>>> M lps/components/extensions/drawview.lzx >>>>> >>>>> Changeset: >>>>> http://svn.openlaszlo.org/openlaszlo/patches/20100219-maxcarlson-3.tar >>>> >>> _______________________________________________ >>> Laszlo-reviews mailing list >>> [email protected] >>> http://www.openlaszlo.org/mailman/listinfo/laszlo-reviews >> > _______________________________________________ > Laszlo-reviews mailing list > [email protected] > http://www.openlaszlo.org/mailman/listinfo/laszlo-reviews _______________________________________________ Laszlo-reviews mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-reviews
