- From: Glenn Maynard <glenn@zewt.org>
- Date: Fri, 26 Jul 2013 09:45:20 -0500
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: whatwg <whatwg@whatwg.org>
On Thu, Jul 25, 2013 at 10:29 PM, Rik Cabanier <cabanier@gmail.com> wrote: > We're getting a bit off track here :-) > We're figuring out an unclear use case. That's as on-track as it gets. :) > No, you need to scale, otherwise the content of your canvas won't scale > up. > For instance, if you have a 100x100 device pixel rect, it has to become a > 110x110 device pixel rect if you zoom by 10% > Okay, that wasn't clear to me. Pixel ratios are peripheral to what you're describing: you could ask for the same thing any time you're rendering to a dynamically-sized canvas, which simplifies the discussion. I don't know if a complex semi-antialiasing mode is a good approach, though. It'll always have issues (rounded corners won't "connect" cleanly; it's not clear if it works for fills, or if it works for patterned fills). I don't know if this would work well in practice, or if it's implementable, but here's a two-part approach that might work: - First, add the inner and/or outer stroke modes. This seems useful in and of itself, but the purpose here is to make it so integer coordinates give hard edges, whether or not you have a 1px stroke. - Second, add a mode which causes coordinates to be snapped to integers. This would happen when you make the API call, and be applied after the canvas transform. If you're in scale(1.25), and you call rect(100, 100, 75, 75), it would draw a rect from 100x100 to 194x194, instead of to 193.75x193.75. This would give clean output for rounded edges, since you're adjusting the size of the path as a whole. It would work for fills (which also get aliased edges when transformed). It also works if the fill is a pattern, where turning off antialiasing would make the pattern ugly. -- Glenn Maynard
Received on Friday, 26 July 2013 14:45:47 UTC