- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 4 Dec 2013 17:21:08 -0800
- To: Jürg Lehni <lists@scratchdisk.com>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
On Wed, Dec 4, 2013 at 11:32 AM, Jürg Lehni <lists@scratchdisk.com> wrote: > > On Nov 29, 2013, at 06:03 , Rik Cabanier <cabanier@gmail.com> wrote: > > > I agree it's not the most useful API but it will be helpful. From one of > the previous message: > > It would be a very fast way to set a cached path in the graphics state > > and: > > In the case of Paper.js, this optimization was not possible precisely > because the returned path has the matrices factored in. The draw loop in > Paper.js iterates through the scene graph (our DOM) and on each level > applies the stored matrix, then draws the item (in case of a group, this > means just iterating through its children and repeating the same thing > again for each child). I was reusing path descriptions through #currentPath > in the Path item for a while, but had to stop using it again since it > appeared to be applying matrices twice. And even if I would have decided to > not apply matrices in such a case (or reset the matrix before drawing such > an already transformed path), I would still end up having troubles as soon > as I would use lineWidth, gradients or patterns, since they are transformed > based on the current matrix too. Even the stroke itself is transformed by > the matrix. > OK, so since the current proposal does NOT bake in the current matrix, it should be possible. > > So other than using it for hit-regions, I really don't think I can see too > many use cases. > > And perhaps that points towards an issue in the specification of > hit-regions? > I'm not sure why that would be. Can you elaborate?
Received on Thursday, 5 December 2013 01:21:35 UTC