Depending on how the Path object gets implemented, there could be a lot more benefits. E.g. the Context could be transformed without transforming the path. It would be possible to get a point at a given length on a path or the path length itself. It would be possible to get a segment on a path or replace it by another one. If the Path would store information about stroke styles, like thickness, we could also get the information if a point is on the stroke of a Path, or the bounding box surrounding a path. All this is part of SVGs path implementation and shouldn't be hard to implement for browser vendors who already support SVG.
Dirk Am 16.11.2010 um 06:38 schrieb Evgeny Burzak: > 2010/11/15 Samuel Ytterbrink <[email protected]>: >> hmm... Can you explain the path-object more in detail. It sounds >> interesting... but why shouldn't i just create a function that takes a >> context and do the same path commands on it instead of having a context >> taking a path object? >> > > In case of >1000 path nodes , path object may save good portion of > time due to caching mechanism. > Inside IExplorer, path is serialized so that , I can drawing even > complicated curves without a hung. > > And technical details: > CanvasPath instance has all canvas path drawings methods , plus: > > append(<path object>) > clone() > push(<segment>) > pop() > > Path segment is just an array, for ex. ["moveTo", [0,0]]. > > In current version nodes are saved in _stack property, but i think > CanvasPath should be special array, so that i can get n-th segment as > path[n]. > > Related methods in canvas context: > > beginPath() - is created new path object inside context > createPath() - creates and returns path obj instance > appendPath() - appends to the current path > clonePath() - clones and returns path obj > > Evgeny
