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
