Seeing what Kornel wrote about a solution to the problem for canvas, makes persuasive support, to me, for Glenn Maynard's argument that [concerning SVG and canvas] " I think they should be two separate discussions."
One of the intentions (at least historically) of SVG is to allow declarative rather than scripted solutions. As I read this conversation from a declarative perspective (trying to transcode script into markup) I am seeing a dozen little flag-attributes that all interact with one another in a grand logical hyperplane. Sorry, for what might be a flawed metaphor, but I've been stuck in a logical hyperplane for the past few days and I am cursing it! Cheers D (Lie algebra is even worse than Lie geometry! -- https://en.wikipedia.org/wiki/Sophus_Lie ) -----Original Message----- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Kornel Lesinski Sent: Tuesday, July 23, 2013 10:09 PM To: Rik Cabanier Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Blurry lines in 2D Canvas (and SVG) On Wed, 24 Jul 2013 02:13:19 +0100, Rik Cabanier <caban...@gmail.com> wrote: >> It's not intuitive. It's a pretty common pitfall, but it's logical. >> >> For 1-pixel lines it could be fixed by allowing authors to specify >> that path should be stroked with lines aligned to inside/outside of >> the path (which is a useful feature on its own). > > > Sure, but how can we fix this? > It's not very intuitive that I have to keep track of the > devicePixelRatio (and the current CTM?) to get crisp lines. To what extent does it need to be "fixed"? "Manually" snapping lines to canvas pixels isn't too hard, e.g. subtracting 0.5 from x/y and adding 1 to width/height to get pixel-aligned rectangle outside the box. It does get trickier with transforms indeed :( Is it enough to snap to canvas pixels? (future of "HD" canvas is uncertain, so authors may need to resize canvas to match devicePixelRatio anyway). Is it enough if there was strokeOutside()/strokeInside() that makes untransformed lines pixel-aligned? Or is it necessary to have snapping for odd-width lines that are stroked centered on a path? Do authors expect lines in canvas with non-integer transforms to be crisp? Should arc() and bezier curves also be snapped? What if you want a line that touches the curve? > What we need is that artwork 'snaps' to the native pixels while still > being antialiased. How should snapping be done? If fill() of a 2x2 rect draws: XX XX how would stroke() look like? .... .XX. .XX. .... or .. .. or ... .X. ... If you have path that is 2.5 device pixels wide, is it going to be snapped to different width depending whether you draw it at (0, 0) or (0.1, 0)? Would that also make circles ellipses? Snapping makes animated slow movement choppy, so authors may also want ability to disable it for selected paths/drawing operations or even for each axis separately (e.g. to smoothly animate horizontal movement while object is snapped to pixels vertically, etc.) -- regards, Kornel
