On 3/5/10 1:52 PM, P T Withington wrote: > 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.
Right - depending on if the value is true/false. > 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? Agreed - since this feature represents a change in behavior, it defaults to false/off. If you want lines aliased, turn it on. > 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
