You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Path2D object has been asked for support for performance reasons since long.
Before we supported browsers that couldn't use it, now we could use it.
How the Path2D object work?
The Path2d is a class where you can add commands exactly as you do with the canvas context2d. https://developer.mozilla.org/en-US/docs/Web/API/Path2D
It is a sort of accumulator of commands that you replay when you want hopefully in an optimized way compared to calling all the JS api one by one.
It is useful at least for:
Polygon
Polyline
Rect with or without rx/ry
Path
Triangle
Node-canvas probably does not support it, but we can easily make a test for it and if is not available we render on the context.
Implementation details
One of the reasons why i didn't add it in a pr quickly is that together with a new cache for drawing commands it comes the needs of a way to invalidate this cache.
The path that define an object changes in a different way compare to the caching of the object itself.
Let's take as an example a simple Path.
if you change the fill color, the cache needs to be invalidated, but the Path2D no.
if you change the scale of the path you need to invalidate the cache but the Path2D no.
if you change a point in the path you need to invalidate both
If you over invalidate the Path2D it is not useful to implement it
For Path, Polygon, Polyline there isn't a a property to change that is going to invalidate points or path, the only possibility is the control api, but i can be clarified that if you mess with the Path or Polyline structure you have to call an invalidation step for the Path2D.
We do no want to implement an auto invalidation in setters for those classes because they will happen by mutation most of the time and so we won't catch them.
For the Rect and Triangle is probably a bit easier since the properties to look for are just width/height and rx/ry
An implementation has to come with a way to benchmark the improvement, we need to be sure we are at least same speed most of the time and we are accelerating some use cases, or is not worth doing.
I do not expect a speed improvement for cached objects at all, but i do for uncached use cases.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The Path2D object has been asked for support for performance reasons since long.
Before we supported browsers that couldn't use it, now we could use it.
How the Path2D object work?
The Path2d is a class where you can add commands exactly as you do with the canvas context2d.
https://developer.mozilla.org/en-US/docs/Web/API/Path2D
It is a sort of accumulator of commands that you replay when you want hopefully in an optimized way compared to calling all the JS api one by one.
It is useful at least for:
Node-canvas probably does not support it, but we can easily make a test for it and if is not available we render on the context.
Implementation details
One of the reasons why i didn't add it in a pr quickly is that together with a new cache for drawing commands it comes the needs of a way to invalidate this cache.
The path that define an object changes in a different way compare to the caching of the object itself.
Let's take as an example a simple Path.
if you change the fill color, the cache needs to be invalidated, but the Path2D no.
if you change the scale of the path you need to invalidate the cache but the Path2D no.
if you change a point in the path you need to invalidate both
If you over invalidate the Path2D it is not useful to implement it
For Path, Polygon, Polyline there isn't a a property to change that is going to invalidate points or path, the only possibility is the control api, but i can be clarified that if you mess with the Path or Polyline structure you have to call an invalidation step for the Path2D.
We do no want to implement an auto invalidation in setters for those classes because they will happen by mutation most of the time and so we won't catch them.
For the Rect and Triangle is probably a bit easier since the properties to look for are just width/height and rx/ry
An implementation has to come with a way to benchmark the improvement, we need to be sure we are at least same speed most of the time and we are accelerating some use cases, or is not worth doing.
I do not expect a speed improvement for cached objects at all, but i do for uncached use cases.
Beta Was this translation helpful? Give feedback.
All reactions