On Nov 29, 2013, at 06:03 , Rik Cabanier <[email protected]> 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. 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? Jürg
