It seems like those should be two separate things instead of lumped all
together in a monolithic You can do this if you want... or whatever!
Snapping is definitely something different than antialiasing. It's a
huge pain for anyone trying to provide a(n accurate) simple 2D primitive
library.
On Sat, Aug 10, 2013 at 9:43 PM, Rik Cabanier caban...@gmail.com wrote:
Ah, so you are relying on pixel snapping (=rounded up to 2 pixels).
Rounded to the nearest integer pixel. If you give 1.25, the width would be
1.
If you can do that with your approach, why not with strokes that are
On Mon, Aug 12, 2013 at 6:45 PM, Glenn Maynard gl...@zewt.org wrote:
On Sat, Aug 10, 2013 at 9:43 PM, Rik Cabanier caban...@gmail.com wrote:
Ah, so you are relying on pixel snapping (=rounded up to 2 pixels).
Rounded to the nearest integer pixel. If you give 1.25, the width would
be 1.
On Fri, Aug 9, 2013 at 10:07 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Aug 9, 2013 at 11:07 PM, Rik Cabanier caban...@gmail.com wrote:
How would you fix a 1.5 pixel width for the stroke or a 1.5 transform?
By snapping the final, post-transform width of the stroke to an integer.
If
I think one problem you might run into is that, if you consider a stroked
line to be centered on pixel centers rather than pixel edges, then the same
path when filled and stroked would touch different pixels along each edge.
Consider a 10x10 rectangle, drawn at coordinates coordinates 5, 5. If
On Fri, Aug 9, 2013 at 4:17 PM, Stephen White senorbla...@chromium.orgwrote:
If the stroke was instead drawn centered over half pixels, the stroked
rects would be centered along (5.5, 5.5) - (14.5, 5.5) - (14.5, 14.5) -
(14.5, 5.5) - (5.5, 5.5). This would touch pixels 5-15 in each dimension.
That's an interesting idea. I suppose the fully general solution would be
to have a stroke offset. E.g., with a stroke width of 4 and and offset of
2 you'd get outer, offset -2 you'd get inner, offset 1 you'd get 3
pixels outer and 1 pixel inner, etc. Dunno how useful that is, though.
Stephen
On Fri, Aug 9, 2013 at 2:17 PM, Stephen White senorbla...@chromium.orgwrote:
I think one problem you might run into is that, if you consider a stroked
line to be centered on pixel centers rather than pixel edges, then the same
path when filled and stroked would touch different pixels along
On Fri, Aug 9, 2013 at 8:16 PM, Rik Cabanier caban...@gmail.com wrote:
On Fri, Aug 9, 2013 at 2:17 PM, Stephen White senorbla...@chromium.orgwrote:
I think one problem you might run into is that, if you consider a stroked
line to be centered on pixel centers rather than pixel edges, then
On Fri, Aug 9, 2013 at 7:16 PM, Rik Cabanier caban...@gmail.com wrote:
In addition if
the corners of the path don't align with the grid, you will get a blurry
outline again.
That's the purpose of the second half of my proposal: snapping coordinates
and line widths to integers.
As an
On Fri, Aug 9, 2013 at 8:12 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Aug 9, 2013 at 7:16 PM, Rik Cabanier caban...@gmail.com wrote:
In addition if
the corners of the path don't align with the grid, you will get a blurry
outline again.
That's the purpose of the second half of my
On Fri, Aug 9, 2013 at 11:07 PM, Rik Cabanier caban...@gmail.com wrote:
How would you fix a 1.5 pixel width for the stroke or a 1.5 transform?
By snapping the final, post-transform width of the stroke to an integer.
If you scale by 1.25, eg. ctx.scale(1.25, 1.25), then draw a stroke with a
On Thu, Jul 25, 2013 at 10:29 PM, Rik Cabanier caban...@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
On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier caban...@gmail.com wrote:
Yes, that's what I had in mind: the developer detects the device pixel
ratio and scales up the canvas so the pixels match.
That reduces to the simple case, then. The pixel ratio gets out of the
picture entirely if you
On Thu, Jul 25, 2013 at 7:05 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier caban...@gmail.com wrote:
Yes, that's what I had in mind: the developer detects the device pixel
ratio and scales up the canvas so the pixels match.
That reduces to the
troubles for D3. Is
that the same issue?
Cheers
David
-Original Message-
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Rik Cabanier
Sent: Tuesday, July 23, 2013 7:19 PM
To: wha...@whatwg.org
Subject: [whatwg] Blurry lines in 2D
On Thu, Jul 25, 2013 at 2:36 PM, Rik Cabanier caban...@gmail.com wrote:
On Thu, Jul 25, 2013 at 7:05 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier caban...@gmail.comwrote:
Yes, that's what I had in mind: the developer detects the device pixel
ratio
On Thu, Jul 25, 2013 at 1:28 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jul 25, 2013 at 2:36 PM, Rik Cabanier caban...@gmail.com wrote:
On Thu, Jul 25, 2013 at 7:05 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier caban...@gmail.comwrote:
Yes,
On Thu, Jul 25, 2013 at 3:49 PM, Rik Cabanier caban...@gmail.com wrote:
You still need the scale though, otherwise the canvas content isn't zoomed
(which is what the user requested)
(We were talking about device pixel ratios, not zooming--user zooming
scales the backing store, which is what
On Thu, Jul 25, 2013 at 3:59 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jul 25, 2013 at 3:49 PM, Rik Cabanier caban...@gmail.com wrote:
You still need the scale though, otherwise the canvas content isn't
zoomed (which is what the user requested)
(We were talking about device pixel
On Jul 24, 2013, at 7:19 AM, Rik Cabanier caban...@gmail.com wrote:
On Tue, Jul 23, 2013 at 6:20 PM, Glenn Maynard gl...@zewt.org wrote:
(The below is about Canvas only; I'm not very familiar with SVG. I think
they should be two separate discussions.)
Agreed. Sorry to confuse the
On Wed, Jul 24, 2013 at 6:20 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Jul 23, 2013 at 11:56 PM, Rik Cabanier caban...@gmail.com wrote:
This happens because you offset 1 pixel and then draw a half pixel
stroke
on each side. Since it covers only half the pixel, the color gets
mapped
On Wed, Jul 24, 2013 at 4:54 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jul 24, 2013 at 1:25 PM, Rik Cabanier caban...@gmail.com wrote:
sorry, that was a typo. I meant to say 'translate(.5, .5)' will offset
your fills.
(All I meant in the first place was that the pixel ratio isn't a
All,
we've noticed that if you draw lines in canvas or SVG, they always end up
blurry.
For instance see this fiddle: http://jsfiddle.net/V92Gn/128/
This happens because you offset 1 pixel and then draw a half pixel stroke
on each side. Since it covers only half the pixel, the color gets mapped
Sent: Tuesday, July 23, 2013 7:19 PM
To: wha...@whatwg.org
Subject: [whatwg] Blurry lines in 2D Canvas (and SVG)
All,
we've noticed that if you draw lines in canvas or SVG, they always end up
blurry.
For instance see this fiddle: http://jsfiddle.net/V92Gn/128/
This happens because you offset 1 pixel
(2013/07/24 8:19), Rik Cabanier wrote:
we've noticed that if you draw lines in canvas or SVG, they always end up
blurry.
For instance see this fiddle: http://jsfiddle.net/V92Gn/128/
As discussed with Rik privately, SVG has shape-rendering: crispEdges for
this.[1]
[1]
On Wed, 24 Jul 2013 01:18:35 +0100, David Dailey
ddai...@zoominternet.net wrote:
Just affirming what you've said in SVG:
http://cs.sru.edu/~ddailey/svg/edgeblurs.svg
The middle rects are crisp, having been merely translated leftward and
downward by half a pixel. Zooming in from the browser
yeah, at first blush that seemed what was needed.
However, this simply turns off antialiasing completely so regular artwork
looks terrible.
On Tue, Jul 23, 2013 at 5:31 PM, Brian Birtles bbirt...@mozilla.com wrote:
(2013/07/24 8:19), Rik Cabanier wrote:
we've noticed that if you draw lines in
(2013/07/24 10:07), Rik Cabanier wrote:
yeah, at first blush that seemed what was needed.
However, this simply turns off antialiasing completely so regular
artwork looks terrible.
That's a quality of implementation issue. The description of the
property value says,
Indicates that the user
On Tue, Jul 23, 2013 at 5:34 PM, Kornel Lesiński kor...@geekhood.netwrote:
On Wed, 24 Jul 2013 01:18:35 +0100, David Dailey ddai...@zoominternet.net
wrote:
Just affirming what you've said in SVG:
http://cs.sru.edu/~ddailey/**svg/edgeblurs.svghttp://cs.sru.edu/~ddailey/svg/edgeblurs.svg
I guess there's too many mights in there :-)
I want to adjust line positions and line widths to align edges with device
pixels but not the user agent might turn off anti-aliasing for all lines
and curves
On Tue, Jul 23, 2013 at 6:11 PM, Brian Birtles bbirt...@mozilla.com wrote:
(2013/07/24
. Is
that the same issue?
Cheers
David
-Original Message-
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Rik Cabanier
Sent: Tuesday, July 23, 2013 7:19 PM
To: wha...@whatwg.org
Subject: [whatwg] Blurry lines in 2D Canvas (and SVG)
All,
we've
(The below is about Canvas only; I'm not very familiar with SVG. I think
they should be two separate discussions.)
On Tue, Jul 23, 2013 at 6:19 PM, Rik Cabanier caban...@gmail.com wrote:
we've noticed that if you draw lines in canvas or SVG, they always end up
blurry.
For instance see this
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
On Tue, Jul 23, 2013 at 6:20 PM, Glenn Maynard gl...@zewt.org wrote:
(The below is about Canvas only; I'm not very familiar with SVG. I think
they should be two separate discussions.)
Agreed. Sorry to confuse the issue.
On Tue, Jul 23, 2013 at 6:19 PM, Rik Cabanier caban...@gmail.com
35 matches
Mail list logo
