Although Skia could support resetClip() via SkRegion::kReplace_Op, it's
problematic for the API in general, and I think we should avoid it.
In particular, it makes it impossible to place a display list (SkPicture in
Skia parlance) inside a parent display list containing a clip and be
assured that
On Fri, 9 Aug 2013, Stephen White wrote:
Although Skia could support resetClip() via SkRegion::kReplace_Op, it's
problematic for the API in general, and I think we should avoid it.
In particular, it makes it impossible to place a display list (SkPicture
in Skia parlance) inside a parent
I originally opened this bug/request for performance reasons, since I try
to avoid all use of save() and restore() on the context. As a refresher
resetting any piece of context state by itself is possible except for
clipping regions.
I do see Rik's point about the mess a resetClip() function
On Mon, 11 Mar 2013, Kenneth Russell wrote:
It would be useful to be able to create an ImageData [1] object with
preexisting data. The main use case is to display arbitrary data in the
2D canvas context with no data copies.
Doesn't ImageBitmap support this already? I'm not sure I understand
On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson i...@hixie.ch wrote:
This is a quite widely requested feature. What should we do to address
this request instead?
What if resetClip restored the clip to what it was at the save call that
created the current state stack level?
In other words,
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 1:32 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 11 Mar 2013, Kenneth Russell wrote:
It would be useful to be able to create an ImageData [1] object with
preexisting data. The main use case is to display arbitrary data in the
2D canvas context with no data copies.
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.
On Fri, 9 Aug 2013, Rik Cabanier wrote:
On Fri, Aug 9, 2013 at 1:32 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 11 Mar 2013, Kenneth Russell wrote:
It would be useful to be able to create an ImageData [1] object with
preexisting data. The main use case is to display arbitrary data in
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 Sat, 16 Mar 2013, Jonas Sicking wrote:
It's currently unclear what to do if a page contains markup like a
href=page.txt download=A.txt if the resource at audio.wav responds
with either
(I'm assuming this is all on the same origin, that there is no script
changing the various attributes,
On Fri, Aug 9, 2013 at 3:53 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 16 Mar 2013, Jonas Sicking wrote:
It's currently unclear what to do if a page contains markup like a
href=page.txt download=A.txt if the resource at audio.wav responds
with either
(I'm assuming this is all on the same
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, 9 Aug 2013, Jonas Sicking wrote:
On Fri, Aug 9, 2013 at 3:53 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 16 Mar 2013, Jonas Sicking wrote:
It's currently unclear what to do if a page contains markup like a
href=page.txt download=A.txt if the resource at audio.wav
responds
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
18 matches
Mail list logo
