[whatwg] fxCanvas 0.2 and some remarks about canvas spec

[Dirk Schulze]

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 <samuel at ytterbrink.nu>:
>> 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