On Fri, 9 Aug 2013, Simon Sarris wrote:
As an alternative [to resetClip()] I would propose something like
setClip() or setClip(path) (with the former working on the current path,
just like clip()/fill()/stroke() does).
Seems like this would have the same problems as resetClip(), since it's
If this is strictly a performance issue, then we definitely should fix
that before adding new API, IMHO. It would be great to get some reduced
test cases where save()/restore() is a bottleneck.
I'd argue its not strictly a performance issue. More generally its awkward
that you can reset any
On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad ju...@google.com wrote:
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
I think most performance-minded use cases will be fine with junov's idea
since they will not want to touch the stack in the first place.
Here's a simple use case: Suppose there are nested objects to be drawn,
Panels, TextBlocks, and other visual elements. Panels are containers that
draw a
On Mon, Aug 12, 2013 at 2:15 PM, Rik Cabanier caban...@gmail.com wrote:
On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad ju...@google.com wrote:
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
On Mon, Aug 12, 2013 at 1:24 PM, Justin Novosad ju...@google.com wrote:
On Mon, Aug 12, 2013 at 2:15 PM, Rik Cabanier caban...@gmail.com wrote:
On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad ju...@google.com wrote:
On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, Aug 12, 2013 at 4:34 PM, Rik Cabanier caban...@gmail.com wrote:
On Mon, Aug 12, 2013 at 1:24 PM, Justin Novosad ju...@google.com wrote:
On Mon, Aug 12, 2013 at 2:15 PM, Rik Cabanier caban...@gmail.com wrote:
On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad ju...@google.com
Good point, I think part of the problem has to do with the fact that save
is non-selective (saves all of the state).
Yes, since save() and restore() save and restore everything, it creates the
side effect of needing to set ctx.font/fillStyle/strokeStyle more often
than otherwise, which are slow
Ok, so here is a simple proposal:
IDL:
enum CanvasSaveMode { all, transform, clip, transform-and-clip };
save(optional CanvasSaveMode mode);
Modes:
all: save the entire rendering context state
transform: save only the current transform
clip: save only the current clip
if mode is not specified,
On Mon, Aug 12, 2013 at 2:26 PM, Justin Novosad ju...@google.com wrote:
Ok, so here is a simple proposal:
IDL:
enum CanvasSaveMode { all, transform, clip, transform-and-clip };
save(optional CanvasSaveMode mode);
Modes:
all: save the entire rendering context state
transform: save only the
If this is strictly a performance issue, then we definitely should fix that
before adding new API, IMHO. It would be great to get some reduced test
cases where save()/restore() is a bottleneck.
(Incidentally, we did some performance fixes recently for setFont() in
Chrome.)
Stephen
On Mon, Aug
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 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,
On Tue, 29 Jan 2013, Rik Cabanier wrote:
we were looking at how resetClip could be implemented in WebKit. Looking
over the Core Graphics implementation, this feature can't be implemented
without significant overhead. I also found an email from 2007 where
Maciej states the same concern:
All,
we were looking at how resetClip [1] could be implemented in WebKit.
Looking over the Core Graphics implementation, this feature can't be
implemented without significant overhead. I also found an email from 2007
where Maciej states the same concern. [2]
Since no browser has implemented it,
I opened the bug about this originally back in 2011, asking that it be
added (it was in March 2012 to the WHATWG spec). For the sake of the
discussion that bug is here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14499
The reason is that (almost) every single piece of canvas context state can
On Tue, Jan 29, 2013 at 5:00 PM, Rik Cabanier caban...@gmail.com wrote:
All,
we were looking at how resetClip [1] could be implemented in WebKit.
Looking over the Core Graphics implementation, this feature can't be
implemented without significant overhead. I also found an email from 2007
On Tue, Jan 29, 2013 at 5:27 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Jan 29, 2013 at 5:00 PM, Rik Cabanier caban...@gmail.com wrote:
All,
we were looking at how resetClip [1] could be implemented in WebKit.
Looking over the Core Graphics implementation, this feature can't
On Tue, Jan 29, 2013 at 6:10 PM, Rik Cabanier caban...@gmail.com wrote:
It restores the graphics state back to the state at 'save' time and this
includes the clip area.
'Clip' is a nested operation so every clip will be the intersection of the
existing clip area and the new one.
PDF also has
On Tue, Jan 29, 2013 at 8:23 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Jan 29, 2013 at 6:10 PM, Rik Cabanier caban...@gmail.com wrote:
It restores the graphics state back to the state at 'save' time and this
includes the clip area.
'Clip' is a nested operation so every clip
On Tue, Jan 29, 2013 at 8:28 PM, Charles Pritchard ch...@jumis.com wrote:
On 1/29/2013 8:23 PM, Tab Atkins Jr. wrote:
On Tue, Jan 29, 2013 at 6:10 PM, Rik Cabanier caban...@gmail.com wrote:
It restores the graphics state back to the state at 'save' time and this
includes the clip area.
23 matches
Mail list logo
