I have been building a Canvas diagramming library since 2010 (
https://gojs.net), if anyone has any questions about 2D Canvas use in the real-world I'd be happy to answer them.
roundRect is great. Though you don't need 4 arcTo in order to make a rounded rect, you can use bezier instead (we do). Their example is also 1% amusing because they set the `fillStyle` but then call `stroke` (and not `fill`). I'll have to do some performance comparisons, since that's the operative thing for my use case (and any library author).
text modifiers are very welcome. It's crazy how annoying measuring still is, especially if you want thinks to look perfectly consistent across browsers. Though the chrome dominance is making things easier in one way, I guess.
context.reset is kinda funny. Most high-performance canvas apps will never want to use it. For that matter you want to set all properties as little as possible, especially setting things like context.font, which are slow even if you're setting it to the same value. (Or it was, I haven't tested that in several years).
I'm sure most users know this by now, but generally for performance the fewer calls you make to the canvas and the context, the beter. This is even true of transforms: It's faster to make your own Matrix class, do all your own matrix translation, rotation, multiplication, etc, and then make a single call to `context.setTransform`, than it is to call the other context methods.
One of the greatest things to happen to 2D canvas in all these years was hardware acceleration. It used to be significantly slower. (You could switch to WebGL canvas, but at a cost of complexity and all kinds of annoyances rendering text, and if you had a lot of text it often wasn't worth it.) Thinking back, I'm also a little disappointed that after the death of Flash, it felt like Canvas never really took its place. The playful web that came before it in some ways simply closed up.
roundRect is great. Though you don't need 4 arcTo in order to make a rounded rect, you can use bezier instead (we do). Their example is also 1% amusing because they set the `fillStyle` but then call `stroke` (and not `fill`). I'll have to do some performance comparisons, since that's the operative thing for my use case (and any library author).
text modifiers are very welcome. It's crazy how annoying measuring still is, especially if you want thinks to look perfectly consistent across browsers. Though the chrome dominance is making things easier in one way, I guess.
context.reset is kinda funny. Most high-performance canvas apps will never want to use it. For that matter you want to set all properties as little as possible, especially setting things like context.font, which are slow even if you're setting it to the same value. (Or it was, I haven't tested that in several years).
I'm sure most users know this by now, but generally for performance the fewer calls you make to the canvas and the context, the beter. This is even true of transforms: It's faster to make your own Matrix class, do all your own matrix translation, rotation, multiplication, etc, and then make a single call to `context.setTransform`, than it is to call the other context methods.
One of the greatest things to happen to 2D canvas in all these years was hardware acceleration. It used to be significantly slower. (You could switch to WebGL canvas, but at a cost of complexity and all kinds of annoyances rendering text, and if you had a lot of text it often wasn't worth it.) Thinking back, I'm also a little disappointed that after the death of Flash, it felt like Canvas never really took its place. The playful web that came before it in some ways simply closed up.