9 ms·

I have been building a Canvas diagramming library since 2010 (https://gojs.net https://gojs.net), if anyone has any questions about 2D Canvas use in the real-wo

I have been building a Canvas diagramming library since 2010 (https://gojs.net 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.

IceDane 5y ago
Your library seems absolutely great. I can't believe I've never stumbled upon it before since I've literally gone looking for stuff exactly like this several times and never found anything very good.
- david927 5y ago
  HN hates "me too" comments but I couldn't agree more. Absolutely stunning job. Great work. I don't know how I didn't know it existed before.
mpmpmpmp 5y ago
What would your strategy for working with raw image data and implementing a digital “zoom” that doesn’t do any anti aliasing or smoothing? My current thought is to just have an original copy of the data and then the current canvas is just a smaller subset of the original data when zoomed. So a 100x100 pixel image when zoomed 1x would take a 50x50 subset based on the center of the viewport and copy each pixel into a 2x2 to get back to a 100x100 image.
- simonsarris 5y ago
  Unless I misunderstand you, you should be able to `ctx.drawImage` from one canvas to another, with `imageSmoothingEnabled` set to false, and it will do what you want. https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/imageSmoothingEnabled https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende...
dmitriid 5y ago
The problem is: browser implementors are never/rarely website implementors. So you always end up with half-baked tangentially useful standards and APIs like this. They just don't know what is actually needed.
- mysteryDate 5y ago
  Well, there's this and the fact that browser implementers all need to come to consensus over what features to add and that's an extremely difficult process to move forward. There also is one big browser implementer who doesn't really want the "playful web" to exist and would prefer that everyone live inside of apps. Edit: To be clear, we all work together and mostly get along. It's a long and arduous process to reach consensus and not everyone's incentives are aligned and this can be frustrating.
  - dmitriid 5y ago
    > There also is one big browser implementer who doesn't really _want_ the "playful web" to exist and would prefer that everyone live inside of apps. No. There's one humongous browser implementer who couldn't care less about consensus or what other browser vendors think. This vendors ships literally hundreds of new APIs every year and pretends they are now standards that everyone else must implement. Too bad developers believe them. BTW, it only took only 8 minutes for my countdown to reach zero: https://news.ycombinator.com/item?id=30555034 https://news.ycombinator.com/item?id=30555034
    - dmitriid 5y ago
      Someone linked "Request for position" on these APIs: https://github.com/mozilla/standards-positions/issues/519#issuecomment-859975125 https://github.com/mozilla/standards-positions/issues/519#is... Here's Mozilla's response: --- start quote --- 4x4 transforms: There are a bunch of implementation concerns here (and mentioned on that issue) with regards to availability on various native 2d backends... Needs more investigation SVG filter interface: We would really rather people use WebGL if you want fast/efficient filters. (I made a number of comments on that issue) As is, we're generally against this one for the time being --- end quote --- There's literally zero response on that from @mysteryDate who is now gaslighting Safari in the comment above, and presenting these API additions as fait accompli. Honestly, at this point any time I see any public Chrome person write anything I immediately assume it's a distortion of reality at best and a blatant lie at worst. And this is always the case. But sure. "Safari is the bad guy".
mysteryDate 5y ago
This is all great feedback! 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 almost entirely due to the javascript engine. We're working on ways to improve it. roundRect is great. Though you don't need 4 arcTo in order to make a rounded rect, you can use bezier instead (we do). Yeah, the example was a little bit humorous, I kinda brute forced it. Their example is also 1% amusing because they set the `fillStyle` but then call `stroke` (and not `fill`). You caught what 100 rounds of edits did not.
- moonchrome 5y ago
  >This is almost entirely due to the javascript engine. We're working on ways to improve it. Is it a logo interpreter built into the rendering engine ? repeat 2 [fd 100 repeat 90 [rt 1 fd 0.3] fd 200 repeat 90 [rt 1 fd 0.3]] A rounded rect !
- danielvaughn 5y ago
  Sounds like you're involved in this effort, so I'm taking the opportunity to ask...what about the TextMetrics API? It's listed as supported by Chrome, but I remember trying it last year and it's definitely not supported. Has there been progress on that front?
hutzlibu 5y ago
"One of the greatest things to happen to 2D canvas in all these years was hardware acceleration." I loved this one, too. Except for the one drawback, getImageData is now very, very slow. And no asynchronous method in sight, that could make it fast again.
- dahart 5y ago
  How slow is it these days? Even readPixels() in OpenGL and hw buffer copies in C++ are “slow” because you’re transferring the image data over your PCI bus. Also curious how & whether an async method could help? Is the problem that getImageData() has to wait to flush all pending draw calls before reading back? Are you thinking of some kind of callback that returns the previous frame’s data, rather than demanding it ‘now’? There probably is room for perf improvement, totally, just curious how you’re imagining it would look and if you have data on where the current bottlenecks are.
  - kllrnohj 5y ago
    PBOs allow for asynchronous readbacks from opengl. It's not slow because of the pcie bus (heck for most devices this is unified memory in the first place, it doesn't hit any bus other than dram). Rather it's slow for the same reason glFinish() is. You're blocking waiting for the results of the asynchronous rendering which you probably also just kicked off right at that point. Also it's not like the opengl is happening on the same thread as the canvas2d (or even the same process), so that's yet more synchronization that a blocking getImageData needs to wait on.
    - dahart 5y ago
      Yeah, exactly, that’s what I’m curious about - if the browser’s renderer is adding significant amounts of delay due to additional synchronization, or if the problem with canvas.getImageData() is the same problem we’ve always had and if the delays are similar. This does make it seem like a callback to receive last frame’s image could be much faster than a synchronous read call, and I’d certainly use that if it existed…
andai 5y ago
>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. I've been wondering if this is cultural or technical. The things that are easy to do get done more, and thus the tech (and how well it's designed) shapes mass behavior and culture. On the other hand, where there's a will to do something, a way will be found, or created... A great example is sending Flash holiday greeting cards in the email. Watching them with my mom is one of my favorite computer-related childhood memories. Yet they seemed to go out of style long before Flash did.
- conductr 5y ago
  My recollection of Flash was it was just an annoyance. I remember avoiding flash websites with the exception being games. And I’m not a huge gamer but I recall a handful of flash games that stole a few days of attention from me. I always find it a bit odd when I hear people have positive nostalgic memories of flash because I had thought everyone equally agreed it was annoying: similar to Java applets, the Real Player, and actually many JavaScript things at the time.
  - benrbray 5y ago
    However much Flash was abused on the web, it was an absolute joy to create games and animations with. There aren't any tools I know of today that allow for the same rapid art+animation+code workflows. I've tried using Canvas2D+JS as well as SVG+JS to do some of the same things, and they don't even come close to Flash!
    - conductr 5y ago
      Interesting account. I was diving into tech around turn off the millennia and I remember spending all of a day or so in action script and went back to the server side stuff. There’s so much game content around I have to believe the void is being met somewhere? Was this just an easy on ramp for low/no experienced folks? I believe that’s how the dreamweaver and other connected adobe products were positioned.
Trufa 5y ago
I actually do if you have the time thanks! Whenever I'm trying to draw curved lines, I always have issues with how they look, they seem to look low quality/pixelated. Like here: https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/bezierCurveTo https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende... In the most basic examples they seem to always produce curves like this. Sorry I don't have more specifics since it's a project I'm not actively working on right now but it was a spine that I never removed. If the questions is too broad, please let me know!
- simonsarris 5y ago
  99% the problem is one of pixel density. That is, you have a 400x400 canvas, and a 400x400 CSS pixel space you are drawing it to, but your devices pixel ratio is higher than 1, so it looks kinda blurry. This is because devices squish more than one "hardware pixel" per CSS pixel. Often at a ratio of 1.5 or 2, or higher. The solution is to make a larger canvas, say, 800x800 and put it into that 400x400 space. Here is an example, using that MDN code, with a 400x400 canvas (red) next to a 800x800 canvas (blue). CSS is forcing them both to appear the same 400x400 size. The blue one should look sharper on most devices. Note how the 800x800 canvas needs to be scaled double with ctx2.scale(2,2) so that it appears correct. https://codepen.io/simonsarris/pen/eYexbOb https://codepen.io/simonsarris/pen/eYexbOb Pixel ratio is variable (window.devicePixelRatio), so this canvas pixel density is something you'll want to programmatically set for each user.
  - Trufa 5y ago
    Dude!! Freaking awesome!! Thanks a bunch!! That's exactly what I was looking for! If you have some sort of ko-fi account or whatever I'll buy you a coffee!
    - simonsarris 5y ago
      Haha well, you could always subscribe to my newsletter for a month. You might get a kick out of it anyway. I'm glad to have solved your mystery!
tuckerpo 5y ago
hey it's the twitter homestead photography guy. nice house, nice software too.
leeoniya 5y ago
> 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). yes, ctx.font mutation still sucks very badly. and you cannot avoid it during drag-resizing a canvas, which is miserable. (i maintain a high perf charting lib). my additional annoyances: https://news.ycombinator.com/item?id=30554387 https://news.ycombinator.com/item?id=30554387
DonHopkins 5y ago
Excellent advice! Your setmatrix advice is unintuitive, but I believe you. The JavaScript/C barrier is expensive, while JavaScript calling JavaScript is optimized up the yin-yang. I love canvas because I cut my teeth on PostScript, and it's basically the PostScript imaging model grown up. What you said about minimizing graphics state changes is an important point, that also applies to PostScript. And a lot of PostScript optimization advice also applies to canvas/JavaScript too, because they're similar in many ways. Glenn Reid (who worked for Adobe, and was the author of the "Green Book" on PostScript language program design) wrote "The Distillery", which I've written about before on HN (link and excerpt below), that was a PostScript program that loaded in and partially evaluated another PostScript drawing program, and output another program that drew the exact same thing, only (usually) much faster and usually smaller. Unless you had any loops, which it would unroll. https://www.donhopkins.com/home/archive/news-tape/utilities/distillery/still.ps https://www.donhopkins.com/home/archive/news-tape/utilities/... One of the most important optimizations it did was to transform all the graphics into the same default coordinate system, and optimize out not only graphics state changes but also importantly calls to gsave/grestore, which could be quite common. https://news.ycombinator.com/item?id=21988195 https://news.ycombinator.com/item?id=21988195 Glenn Reid described his classic "Grandfather Clock" metaphor to comp.lang.postscript that really opened my eyes about writing code in interpreted languages like PostScript (and JavaScript, while JIT'ed at runtime, still makes calling native code expensive), and balancing optimization with readability. With modern JavaScript/canvas, JavaScript code that calls other JavaScript code runs really fast, but calling between JavaScript and built-in code is still slow, so it's good to have the built-in code do as much as possible when you do (like rendering a long string of text at once, instead of rendering it word by word like many PostScript drivers would): Glenn's post in a comp.lang.postscript discussion about PostScript programming style and optimization: https://groups.google.com/forum/#!search/%22glenn$20reid%22$20%22grandfather$20clock%22/comp.lang.postscript/i4NcunJGFkU/Boxz_6s-T3cJ https://groups.google.com/forum/#!search/%22glenn$20reid%22$... From: Glenn Reid (Abode Systems) Newsgroup: comp.lang.postscript Subject: Re: An Idea to Help Make Postscript Easier to Read (and Write) Date: 10 Sep 88 17:26:24 GMT You people tend to forget that the PostScript language is interpreted. It is well and good to use tools to convert to and from PostScript, but it is not quite as "transparent" as we all might think. I like to think of a big grandfather clock, with the pendulum swinging. Each time pendulum swings, the PostScript interpreter gets to do one operation. The "granularity" of the clock is nowhere near the speed of a microprocessor instruction set, and any comparison with assembly languages doesn't make sense. The difference between: 0 0 moveto and 0 0 /arg2 exch def /arg1 exch def arg1 arg2 moveto can sort of be measured in "ticks" of the interpreter's clock. It's not quite this simple, since simply pushing a literal is faster than executing a real PostScript operator, but it is a rough rule of thumb. It will take about three times as long to execute the second of these in a tight loop, and about five times as long if it is transmitted and scanned each time. My rule of thumb is that if you have roughly the same number of tokens in your stack approach as you do with your 'exch def' approach, the 'exch def' is likely to be much more readable and better. Otherwise, I usually go with the stack approach. One other thing of note is that if you have too much stack manipulation going on, it may well be symptomatic of a problem in the original program design. Also, most procedures don't do any stack manipulation at all, they simply use their arguments directly from the stack. In this situation, it is especially wasteful (and confusing, I think) to declare intermediate variables. Compare: % sample procedure call: (Text) 100 100 12 /Times-Roman SETTEXT % approach 1: /SETTEXT { %def findfont exch scalefont setfont moveto show } def % approach 2: /SETTEXT { %def /arg5 exch def /arg4 exch def /arg3 exch def /arg2 exch def /arg1 exch def arg5 findfont arg4 scalefont setfont arg2 arg3 moveto arg1 show } def Which of these is easier for you to understand? Anyway, I think the discussion is a good one, but let's not forget that PostScript it is an interpreted language. And I don't think it is terribly hard to use and understand, if it is written well. Glenn Reid Adobe Systems Here's Glenn's "Green Book", which was like a bible to me, and still is quite relevant to canvas 2d context programming -- see especially page 9, section 1.5, Program Design Guidelines, page 72, section 4.6, Optimizing Translator Output, and page 99, chapter 7, The Mechanics of Setting Text: https://www-cdf.fnal.gov/offline/PostScript/GREENBK.PDF https://www-cdf.fnal.gov/offline/PostScript/GREENBK.PDF >page 9: 1.5 Program Design Guidelines >There are a few items that may be kept in mind while implementing a driver for a PostScript device. As with most software development, the most difficult part of writing programs in the PostScript language is the design of the program. If the design is good, implementing it is easy. If the design is poor, it may not even be possible to correctly implement it. Below are some helpful items to keep in mind when writing your software. All of them are explained more fully within the text of this book; this is only an attempt to prime the pump before you start reading: >• Use the operand stack efficiently. Pay particular attention to the order of the elements on the stack and how they are used. (Using the stack efficiently by designing fluent words that chain and dovetail together elegantly in pipelines (and systematically writing line-by-line stack comments) instead of using named variables in dictionaries is good idiomatic PostScript and Forth, aka tacit programming or point-free style, the stack-based equivalent of fluent interfaces.) https://en.wikipedia.org/wiki/Tacit_programming https://en.wikipedia.org/wiki/Tacit_programming https://en.wikipedia.org/wiki/Fluent_interface https://en.wikipedia.org/wiki/Fluent_interface >• Avoid unnecessary redundancy. When a program is produced, check for many repetitive steps that perhaps could be condensed. Keep identifiers short if they are to be transmitted many times. (Only create paths once!) >• Use the PostScript imaging model effectively. When printing, a document must be translated into the language of the printer. This includes a philosophical adjustment to the nature of the PostScript imaging model. (Use the graphics state stack!) >• It is better to translate into the PostScript imaging model than to maintain another set of graphics primitives using the PostScript language for emulation. The hardest problem I ever tried (and failed) to solve properly with PostScript was making a printer driver for rendering user interfaces drawn with X11 using a combination of bitmaps and lines, that looked perfect on the screen at 1:1 scale, but didn't look terrible when you zoomed into them or printed them at high resolution on paper. Because of X11 "half open" pixel rounding rules versus PostScript's "stencil paint" model, they just don't line up right when you zoom into them, and there's no fudge or compromise that works in all cases. Here is my commented-out failed attempt:) https://github.com/mmontone/garnet/blob/1652af38f76b1c4efb19bc31cfbae9197817a786/src/ps/ps.lisp https://github.com/mmontone/garnet/blob/1652af38f76b1c4efb19... line-color line-cap line-join dash-pattern thickness % dup -1 ne { .5 add } if % fudge outline width thicker StrokeShape >page 100: Note: There is one principle to keep in mind when deciding upon an algorithm for setting text. The longer the string presented to one of the show operators, the more efficient the system is likely to be. This is because the PostScript language built-in operators, such as show, widthshow, and ashow, operate essentially at compiled speed once they have been invoked. Each moveto or div operation performed must first be interpreted, which is significantly slower. Here's a description of Glenn's PostScript Distillery, which foreshadowed Acrobat Distiller. https://news.ycombinator.com/item?id=28115946 https://news.ycombinator.com/item?id=28115946 >Glenn Reid wrote a PostScript partial evaluator in PostScript that optimized other PostScript drawing programs, called "The Distillery". You would send still.ps to your PostScript printer, and then send another PostScript file that drew something to the printer. The first PostScript Distillery program would then partially evaluate the second PostScript drawing program, and send back a third PostScript program, an optimized drawing program, with all the loops and conditionals unrolled, calculations and transformations pre-computed, all in the same coordinate system. >It was originally John Warnock's idea, that Glenn implemented. And it led to Adobe Acrobat's "Distiller". Acrobat is basically PostScript without the programming language. >No, you could not make it optimize itself by sending it to a PostScript printer two times in a row. It was not magic: all it did was intercept and capture the side-effects of the PostScript drawing commands (fill, stroke, show), read out the path, and optimize it in a uniform coordinate system. Since it didn't do any drawing, so it would just output an empty program if run on itself. (Take that, halting problem!) https://donhopkins.com/home/archive/postscript/newerstill.ps.txt https://donhopkins.com/home/archive/postscript/newerstill.ps... >From: greid@adobe.com (Glenn Reid) Newsgroups: comp.lang.postscript Subject: release 10 of the Distillery Date: 10 Mar 89 10:21:52 GMT >Here is another release of the PostScript Language Distillery. I know it's not terribly long after the last release, but there are some significant enhancements, and I thought it would be worthwhile. >I finally took a closer look at user-defined fonts, which now seem to be working fairly well. In particular, it seems to handle the Macintosh screen bitmap fonts that get used if the native font is unavailable when the print file is genreated. The entire user-defined font is reverse-engineered to the output file as it stands, and is used exactly like the original file used it. I also fixed some rotate text bugs, rotated charpath, and a few other things. >I want to emphasize that probably the two best uses of this program, currently, are to do speed comparisons of various PostScript language drivers and to convert "non-conforming" files into "conforming" files. It is not particularly well suited to carefully hand-written programs, especially not those which use looping constructs. It works (usually), but it unrolls the loops and makes the files much bigger.
c_s_guy 5y ago
> Though you don't need 4 arcTo in order to make a rounded rect, you can use bezier instead (we do) I'm pretty new to this - do you have an example of using bezier? And why is it preferred over arcTo?
- leeoniya 5y ago
  i think you'd still need 4 bezierCurveTo commands, so not sure there's any advantage over 4 arcTo: function roundedRect(ctx, x, y, width, height, radius) { ctx.beginPath(); ctx.moveTo(x, y + radius); ctx.arcTo(x, y + height, x + radius, y + height, radius); ctx.arcTo(x + width, y + height, x + width, y + height - radius, radius); ctx.arcTo(x + width, y, x + width - radius, y, radius); ctx.arcTo(x, y, x, y + radius, radius); ctx.stroke(); } https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Drawing_shapes#making_combinations https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/...
- ygra 5y ago
  You can use cubic Bézier curves to approximate a circular arc: https://pomax.github.io/bezierinfo/#circles_cubic https://pomax.github.io/bezierinfo/#circles_cubic. In many cases that's even how circular arcs are rendered, even when they are represented with a different data structure. You'll often see the the constant 0.5522... which is for quarter circles. E.g. both WPF and Java's Swing render arcs with that approximation, perhaps others, but those where the places where I checked the source code recently. The benefit of doing this for quarter-circle arcs directly may be that you save a bunch of trigonometry that otherwise has to happen (cf. the Pomax link).
inDigiNeous 5y ago
Interesting to hear about that doing the matrix translations on the js side are faster. Have you benchmarked this recently ? Will have to test it out myself, was under the naive impression that the underlying implementation would be optimal.
- simonsarris 5y ago
  Imagine something like: var transform = ...your own data structure transform.scale(zzz); transform.rotate(zzz); transform.translate(zzz); transform.scale(zzz); // perhaps as many as 50 as you go down the visual tree ctx.setTransform(use your data structure to set these values); This is a little faster than calling all the corresponding methods on ctx. Of course you gotta implement a transform class. And of course it becomes meaningfully faster if you are drawing a large number of objects in a visual tree, and their locations do not all change, so you can save these transforms that you've created, and then the only thing you are doing in the draw loop is a single call to `ctx.setTransform` instead of all the calls you'd normally need. Again this really depends on what you're doing, but you can imagine for drawing the visual tree of a diagram, it can be quite an improvement.

IceDane 5y ago

Your library seems absolutely great. I can't believe I've never stumbled upon it before since I've literally gone looking for stuff exactly like this several times and never found anything very good.

david927 5y ago
HN hates "me too" comments but I couldn't agree more. Absolutely stunning job. Great work. I don't know how I didn't know it existed before.

mpmpmpmp 5y ago

What would your strategy for working with raw image data and implementing a digital “zoom” that doesn’t do any anti aliasing or smoothing? My current thought is to just have an original copy of the data and then the current canvas is just a smaller subset of the original data when zoomed. So a 100x100 pixel image when zoomed 1x would take a 50x50 subset based on the center of the viewport and copy each pixel into a 2x2 to get back to a 100x100 image.

simonsarris 5y ago
Unless I misunderstand you, you should be able to `ctx.drawImage` from one canvas to another, with `imageSmoothingEnabled` set to false, and it will do what you want. https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/imageSmoothingEnabled https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende...

dmitriid 5y ago

The problem is: browser implementors are never/rarely website implementors. So you always end up with half-baked tangentially useful standards and APIs like this. They just don't know what is actually needed.

mysteryDate 5y ago
Well, there's this and the fact that browser implementers all need to come to consensus over what features to add and that's an extremely difficult process to move forward. There also is one big browser implementer who doesn't really want the "playful web" to exist and would prefer that everyone live inside of apps. Edit: To be clear, we all work together and mostly get along. It's a long and arduous process to reach consensus and not everyone's incentives are aligned and this can be frustrating.
- dmitriid 5y ago
  > There also is one big browser implementer who doesn't really _want_ the "playful web" to exist and would prefer that everyone live inside of apps. No. There's one humongous browser implementer who couldn't care less about consensus or what other browser vendors think. This vendors ships literally hundreds of new APIs every year and pretends they are now standards that everyone else must implement. Too bad developers believe them. BTW, it only took only 8 minutes for my countdown to reach zero: https://news.ycombinator.com/item?id=30555034 https://news.ycombinator.com/item?id=30555034
  - dmitriid 5y ago
    Someone linked "Request for position" on these APIs: https://github.com/mozilla/standards-positions/issues/519#issuecomment-859975125 https://github.com/mozilla/standards-positions/issues/519#is... Here's Mozilla's response: --- start quote --- 4x4 transforms: There are a bunch of implementation concerns here (and mentioned on that issue) with regards to availability on various native 2d backends... Needs more investigation SVG filter interface: We would really rather people use WebGL if you want fast/efficient filters. (I made a number of comments on that issue) As is, we're generally against this one for the time being --- end quote --- There's literally zero response on that from @mysteryDate who is now gaslighting Safari in the comment above, and presenting these API additions as fait accompli. Honestly, at this point any time I see any public Chrome person write anything I immediately assume it's a distortion of reality at best and a blatant lie at worst. And this is always the case. But sure. "Safari is the bad guy".

mysteryDate 5y ago

This is all great feedback! 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 almost entirely due to the javascript engine. We're working on ways to improve it. roundRect is great. Though you don't need 4 arcTo in order to make a rounded rect, you can use bezier instead (we do). Yeah, the example was a little bit humorous, I kinda brute forced it. Their example is also 1% amusing because they set the `fillStyle` but then call `stroke` (and not `fill`). You caught what 100 rounds of edits did not.

moonchrome 5y ago
>This is almost entirely due to the javascript engine. We're working on ways to improve it. Is it a logo interpreter built into the rendering engine ? repeat 2 [fd 100 repeat 90 [rt 1 fd 0.3] fd 200 repeat 90 [rt 1 fd 0.3]] A rounded rect !
danielvaughn 5y ago
Sounds like you're involved in this effort, so I'm taking the opportunity to ask...what about the TextMetrics API? It's listed as supported by Chrome, but I remember trying it last year and it's definitely not supported. Has there been progress on that front?

hutzlibu 5y ago

"One of the greatest things to happen to 2D canvas in all these years was hardware acceleration." I loved this one, too. Except for the one drawback, getImageData is now very, very slow. And no asynchronous method in sight, that could make it fast again.

dahart 5y ago
How slow is it these days? Even readPixels() in OpenGL and hw buffer copies in C++ are “slow” because you’re transferring the image data over your PCI bus. Also curious how & whether an async method could help? Is the problem that getImageData() has to wait to flush all pending draw calls before reading back? Are you thinking of some kind of callback that returns the previous frame’s data, rather than demanding it ‘now’? There probably is room for perf improvement, totally, just curious how you’re imagining it would look and if you have data on where the current bottlenecks are.
- kllrnohj 5y ago
  PBOs allow for asynchronous readbacks from opengl. It's not slow because of the pcie bus (heck for most devices this is unified memory in the first place, it doesn't hit any bus other than dram). Rather it's slow for the same reason glFinish() is. You're blocking waiting for the results of the asynchronous rendering which you probably also just kicked off right at that point. Also it's not like the opengl is happening on the same thread as the canvas2d (or even the same process), so that's yet more synchronization that a blocking getImageData needs to wait on.
  - dahart 5y ago
    Yeah, exactly, that’s what I’m curious about - if the browser’s renderer is adding significant amounts of delay due to additional synchronization, or if the problem with canvas.getImageData() is the same problem we’ve always had and if the delays are similar. This does make it seem like a callback to receive last frame’s image could be much faster than a synchronous read call, and I’d certainly use that if it existed…

andai 5y ago

>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. I've been wondering if this is cultural or technical. The things that are easy to do get done more, and thus the tech (and how well it's designed) shapes mass behavior and culture. On the other hand, where there's a will to do something, a way will be found, or created... A great example is sending Flash holiday greeting cards in the email. Watching them with my mom is one of my favorite computer-related childhood memories. Yet they seemed to go out of style long before Flash did.

conductr 5y ago
My recollection of Flash was it was just an annoyance. I remember avoiding flash websites with the exception being games. And I’m not a huge gamer but I recall a handful of flash games that stole a few days of attention from me. I always find it a bit odd when I hear people have positive nostalgic memories of flash because I had thought everyone equally agreed it was annoying: similar to Java applets, the Real Player, and actually many JavaScript things at the time.
- benrbray 5y ago
  However much Flash was abused on the web, it was an absolute joy to create games and animations with. There aren't any tools I know of today that allow for the same rapid art+animation+code workflows. I've tried using Canvas2D+JS as well as SVG+JS to do some of the same things, and they don't even come close to Flash!
  - conductr 5y ago
    Interesting account. I was diving into tech around turn off the millennia and I remember spending all of a day or so in action script and went back to the server side stuff. There’s so much game content around I have to believe the void is being met somewhere? Was this just an easy on ramp for low/no experienced folks? I believe that’s how the dreamweaver and other connected adobe products were positioned.

Trufa 5y ago

I actually do if you have the time thanks! Whenever I'm trying to draw curved lines, I always have issues with how they look, they seem to look low quality/pixelated. Like here: https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/bezierCurveTo https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende... In the most basic examples they seem to always produce curves like this. Sorry I don't have more specifics since it's a project I'm not actively working on right now but it was a spine that I never removed. If the questions is too broad, please let me know!

simonsarris 5y ago
99% the problem is one of pixel density. That is, you have a 400x400 canvas, and a 400x400 CSS pixel space you are drawing it to, but your devices pixel ratio is higher than 1, so it looks kinda blurry. This is because devices squish more than one "hardware pixel" per CSS pixel. Often at a ratio of 1.5 or 2, or higher. The solution is to make a larger canvas, say, 800x800 and put it into that 400x400 space. Here is an example, using that MDN code, with a 400x400 canvas (red) next to a 800x800 canvas (blue). CSS is forcing them both to appear the same 400x400 size. The blue one should look sharper on most devices. Note how the 800x800 canvas needs to be scaled double with ctx2.scale(2,2) so that it appears correct. https://codepen.io/simonsarris/pen/eYexbOb https://codepen.io/simonsarris/pen/eYexbOb Pixel ratio is variable (window.devicePixelRatio), so this canvas pixel density is something you'll want to programmatically set for each user.
- Trufa 5y ago
  Dude!! Freaking awesome!! Thanks a bunch!! That's exactly what I was looking for! If you have some sort of ko-fi account or whatever I'll buy you a coffee!
  - simonsarris 5y ago
    Haha well, you could always subscribe to my newsletter for a month. You might get a kick out of it anyway. I'm glad to have solved your mystery!

tuckerpo 5y ago

hey it's the twitter homestead photography guy. nice house, nice software too.

leeoniya 5y ago

> 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). yes, ctx.font mutation still sucks very badly. and you cannot avoid it during drag-resizing a canvas, which is miserable. (i maintain a high perf charting lib). my additional annoyances: https://news.ycombinator.com/item?id=30554387 https://news.ycombinator.com/item?id=30554387

DonHopkins 5y ago

Excellent advice! Your setmatrix advice is unintuitive, but I believe you. The JavaScript/C barrier is expensive, while JavaScript calling JavaScript is optimized up the yin-yang. I love canvas because I cut my teeth on PostScript, and it's basically the PostScript imaging model grown up. What you said about minimizing graphics state changes is an important point, that also applies to PostScript. And a lot of PostScript optimization advice also applies to canvas/JavaScript too, because they're similar in many ways. Glenn Reid (who worked for Adobe, and was the author of the "Green Book" on PostScript language program design) wrote "The Distillery", which I've written about before on HN (link and excerpt below), that was a PostScript program that loaded in and partially evaluated another PostScript drawing program, and output another program that drew the exact same thing, only (usually) much faster and usually smaller. Unless you had any loops, which it would unroll. https://www.donhopkins.com/home/archive/news-tape/utilities/distillery/still.ps https://www.donhopkins.com/home/archive/news-tape/utilities/... One of the most important optimizations it did was to transform all the graphics into the same default coordinate system, and optimize out not only graphics state changes but also importantly calls to gsave/grestore, which could be quite common. https://news.ycombinator.com/item?id=21988195 https://news.ycombinator.com/item?id=21988195 Glenn Reid described his classic "Grandfather Clock" metaphor to comp.lang.postscript that really opened my eyes about writing code in interpreted languages like PostScript (and JavaScript, while JIT'ed at runtime, still makes calling native code expensive), and balancing optimization with readability. With modern JavaScript/canvas, JavaScript code that calls other JavaScript code runs really fast, but calling between JavaScript and built-in code is still slow, so it's good to have the built-in code do as much as possible when you do (like rendering a long string of text at once, instead of rendering it word by word like many PostScript drivers would): Glenn's post in a comp.lang.postscript discussion about PostScript programming style and optimization: https://groups.google.com/forum/#!search/%22glenn$20reid%22$20%22grandfather$20clock%22/comp.lang.postscript/i4NcunJGFkU/Boxz_6s-T3cJ https://groups.google.com/forum/#!search/%22glenn$20reid%22$... From: Glenn Reid (Abode Systems) Newsgroup: comp.lang.postscript Subject: Re: An Idea to Help Make Postscript Easier to Read (and Write) Date: 10 Sep 88 17:26:24 GMT You people tend to forget that the PostScript language is interpreted. It is well and good to use tools to convert to and from PostScript, but it is not quite as "transparent" as we all might think. I like to think of a big grandfather clock, with the pendulum swinging. Each time pendulum swings, the PostScript interpreter gets to do one operation. The "granularity" of the clock is nowhere near the speed of a microprocessor instruction set, and any comparison with assembly languages doesn't make sense. The difference between: 0 0 moveto and 0 0 /arg2 exch def /arg1 exch def arg1 arg2 moveto can sort of be measured in "ticks" of the interpreter's clock. It's not quite this simple, since simply pushing a literal is faster than executing a real PostScript operator, but it is a rough rule of thumb. It will take about three times as long to execute the second of these in a tight loop, and about five times as long if it is transmitted and scanned each time. My rule of thumb is that if you have roughly the same number of tokens in your stack approach as you do with your 'exch def' approach, the 'exch def' is likely to be much more readable and better. Otherwise, I usually go with the stack approach. One other thing of note is that if you have too much stack manipulation going on, it may well be symptomatic of a problem in the original program design. Also, most procedures don't do any stack manipulation at all, they simply use their arguments directly from the stack. In this situation, it is especially wasteful (and confusing, I think) to declare intermediate variables. Compare: % sample procedure call: (Text) 100 100 12 /Times-Roman SETTEXT % approach 1: /SETTEXT { %def findfont exch scalefont setfont moveto show } def % approach 2: /SETTEXT { %def /arg5 exch def /arg4 exch def /arg3 exch def /arg2 exch def /arg1 exch def arg5 findfont arg4 scalefont setfont arg2 arg3 moveto arg1 show } def Which of these is easier for you to understand? Anyway, I think the discussion is a good one, but let's not forget that PostScript it is an interpreted language. And I don't think it is terribly hard to use and understand, if it is written well. Glenn Reid Adobe Systems Here's Glenn's "Green Book", which was like a bible to me, and still is quite relevant to canvas 2d context programming -- see especially page 9, section 1.5, Program Design Guidelines, page 72, section 4.6, Optimizing Translator Output, and page 99, chapter 7, The Mechanics of Setting Text: https://www-cdf.fnal.gov/offline/PostScript/GREENBK.PDF https://www-cdf.fnal.gov/offline/PostScript/GREENBK.PDF >page 9: 1.5 Program Design Guidelines >There are a few items that may be kept in mind while implementing a driver for a PostScript device. As with most software development, the most difficult part of writing programs in the PostScript language is the design of the program. If the design is good, implementing it is easy. If the design is poor, it may not even be possible to correctly implement it. Below are some helpful items to keep in mind when writing your software. All of them are explained more fully within the text of this book; this is only an attempt to prime the pump before you start reading: >• Use the operand stack efficiently. Pay particular attention to the order of the elements on the stack and how they are used. (Using the stack efficiently by designing fluent words that chain and dovetail together elegantly in pipelines (and systematically writing line-by-line stack comments) instead of using named variables in dictionaries is good idiomatic PostScript and Forth, aka tacit programming or point-free style, the stack-based equivalent of fluent interfaces.) https://en.wikipedia.org/wiki/Tacit_programming https://en.wikipedia.org/wiki/Tacit_programming https://en.wikipedia.org/wiki/Fluent_interface https://en.wikipedia.org/wiki/Fluent_interface >• Avoid unnecessary redundancy. When a program is produced, check for many repetitive steps that perhaps could be condensed. Keep identifiers short if they are to be transmitted many times. (Only create paths once!) >• Use the PostScript imaging model effectively. When printing, a document must be translated into the language of the printer. This includes a philosophical adjustment to the nature of the PostScript imaging model. (Use the graphics state stack!) >• It is better to translate into the PostScript imaging model than to maintain another set of graphics primitives using the PostScript language for emulation. The hardest problem I ever tried (and failed) to solve properly with PostScript was making a printer driver for rendering user interfaces drawn with X11 using a combination of bitmaps and lines, that looked perfect on the screen at 1:1 scale, but didn't look terrible when you zoomed into them or printed them at high resolution on paper. Because of X11 "half open" pixel rounding rules versus PostScript's "stencil paint" model, they just don't line up right when you zoom into them, and there's no fudge or compromise that works in all cases. Here is my commented-out failed attempt:) https://github.com/mmontone/garnet/blob/1652af38f76b1c4efb19bc31cfbae9197817a786/src/ps/ps.lisp https://github.com/mmontone/garnet/blob/1652af38f76b1c4efb19... line-color line-cap line-join dash-pattern thickness % dup -1 ne { .5 add } if % fudge outline width thicker StrokeShape >page 100: Note: There is one principle to keep in mind when deciding upon an algorithm for setting text. The longer the string presented to one of the show operators, the more efficient the system is likely to be. This is because the PostScript language built-in operators, such as show, widthshow, and ashow, operate essentially at compiled speed once they have been invoked. Each moveto or div operation performed must first be interpreted, which is significantly slower. Here's a description of Glenn's PostScript Distillery, which foreshadowed Acrobat Distiller. https://news.ycombinator.com/item?id=28115946 https://news.ycombinator.com/item?id=28115946 >Glenn Reid wrote a PostScript partial evaluator in PostScript that optimized other PostScript drawing programs, called "The Distillery". You would send still.ps to your PostScript printer, and then send another PostScript file that drew something to the printer. The first PostScript Distillery program would then partially evaluate the second PostScript drawing program, and send back a third PostScript program, an optimized drawing program, with all the loops and conditionals unrolled, calculations and transformations pre-computed, all in the same coordinate system. >It was originally John Warnock's idea, that Glenn implemented. And it led to Adobe Acrobat's "Distiller". Acrobat is basically PostScript without the programming language. >No, you could not make it optimize itself by sending it to a PostScript printer two times in a row. It was not magic: all it did was intercept and capture the side-effects of the PostScript drawing commands (fill, stroke, show), read out the path, and optimize it in a uniform coordinate system. Since it didn't do any drawing, so it would just output an empty program if run on itself. (Take that, halting problem!) https://donhopkins.com/home/archive/postscript/newerstill.ps.txt https://donhopkins.com/home/archive/postscript/newerstill.ps... >From: greid@adobe.com (Glenn Reid) Newsgroups: comp.lang.postscript Subject: release 10 of the Distillery Date: 10 Mar 89 10:21:52 GMT >Here is another release of the PostScript Language Distillery. I know it's not terribly long after the last release, but there are some significant enhancements, and I thought it would be worthwhile. >I finally took a closer look at user-defined fonts, which now seem to be working fairly well. In particular, it seems to handle the Macintosh screen bitmap fonts that get used if the native font is unavailable when the print file is genreated. The entire user-defined font is reverse-engineered to the output file as it stands, and is used exactly like the original file used it. I also fixed some rotate text bugs, rotated charpath, and a few other things. >I want to emphasize that probably the two best uses of this program, currently, are to do speed comparisons of various PostScript language drivers and to convert "non-conforming" files into "conforming" files. It is not particularly well suited to carefully hand-written programs, especially not those which use looping constructs. It works (usually), but it unrolls the loops and makes the files much bigger.

c_s_guy 5y ago

> Though you don't need 4 arcTo in order to make a rounded rect, you can use bezier instead (we do) I'm pretty new to this - do you have an example of using bezier? And why is it preferred over arcTo?

leeoniya 5y ago
i think you'd still need 4 bezierCurveTo commands, so not sure there's any advantage over 4 arcTo: function roundedRect(ctx, x, y, width, height, radius) { ctx.beginPath(); ctx.moveTo(x, y + radius); ctx.arcTo(x, y + height, x + radius, y + height, radius); ctx.arcTo(x + width, y + height, x + width, y + height - radius, radius); ctx.arcTo(x + width, y, x + width - radius, y, radius); ctx.arcTo(x, y, x, y + radius, radius); ctx.stroke(); } https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Drawing_shapes#making_combinations https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/...
ygra 5y ago
You can use cubic Bézier curves to approximate a circular arc: https://pomax.github.io/bezierinfo/#circles_cubic https://pomax.github.io/bezierinfo/#circles_cubic. In many cases that's even how circular arcs are rendered, even when they are represented with a different data structure. You'll often see the the constant 0.5522... which is for quarter circles. E.g. both WPF and Java's Swing render arcs with that approximation, perhaps others, but those where the places where I checked the source code recently. The benefit of doing this for quarter-circle arcs directly may be that you save a bunch of trigonometry that otherwise has to happen (cf. the Pomax link).

inDigiNeous 5y ago

Interesting to hear about that doing the matrix translations on the js side are faster. Have you benchmarked this recently ? Will have to test it out myself, was under the naive impression that the underlying implementation would be optimal.

simonsarris 5y ago
Imagine something like: var transform = ...your own data structure transform.scale(zzz); transform.rotate(zzz); transform.translate(zzz); transform.scale(zzz); // perhaps as many as 50 as you go down the visual tree ctx.setTransform(use your data structure to set these values); This is a little faster than calling all the corresponding methods on ctx. Of course you gotta implement a transform class. And of course it becomes meaningfully faster if you are drawing a large number of objects in a visual tree, and their locations do not all change, so you can save these transforms that you've created, and then the only thing you are doing in the draw loop is a single call to `ctx.setTransform` instead of all the calls you'd normally need. Again this really depends on what you're doing, but you can imagine for drawing the visual tree of a diagram, it can be quite an improvement.