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.
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`).
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]]
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.
OTOH, I used to know a bunch of artistic types that had pirated copies and would sit around and create flash animations for their bands/etc. Now those people just do video editing and post things to youtube/etc, or spend time editing photos for facebook/etc. There isn't a hypercard/programming aspect anymore buried under their tooling.
edit: actually it looks like wick can do the hypercard/flash programming too, which is sorta cool.
Distributing a HTML file and its assets? God damn complex
There's always Web Bundles[0], but I have no idea what the UX is like. I haven't heard about Web Bundles for a while, but they seem like such a good idea.
The closest thing would be the mobile games like Candy Crush and Garden Saga, but even there the tide has passed, and it's too difficult to make anything - King was bought by Activision for 6 billion dollars.
Really? Or did move to a platform like App Store/Steam. I’ve seen it quantified and there’s a absurd amount of new games posted daily. I won’t argue that the tools in use are easier or better than flash, but developers certainly pivoted or so it seems. From a laymen/consumer perspective, Browsing the App Store doesn’t feel much different that I remember Kongregate or some of the other big flash game sites of the past.
One of the best languages ever made, imho.
Optional typing, e4x, normal inheritance (non-prototypal), etc...
The web would be a better place if AS3 took over instead of js (and I love js).
I imagine wasm would have shown up and been a ton easier to implement as well. AOT bits that are full static, JIT bits that aren't. No need for TypeScript, Flow, etc...
Especially sad since iirc Adobe donated the entire thing and was pushing for it to become standard in HTML4.
I loved Jobs' vision of HTML5 being the app platform, and getting rid of flash.
Instead he got voted down, and we got the early death of flash with the replacement being a walled-garden app store, setting the web back for years.
They're starting to get their act together (I'm looking at you Web Push Notifications) but it's been a long, painful road.
Say what you want about the underlying tech, the authoring tools were easy for a kind (like me, at the time) to pick up and make animations with.
Is there an equivalent for Canvas?
They are based on some element of surprise. Once the surprise is gone because you've seen it a few times, the joy evaporates and then it's just annoying.
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
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/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!
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
Pixel ratio is variable (window.devicePixelRatio), so this canvas pixel density is something you'll want to programmatically set for each user.
https://github.com/leeoniya/uPlot/blob/190134aa844cfa2a0c052...
everything stays crisp even as you browser-zoom. e.g. https://leeoniya.github.io/uPlot/demos/area-fill.html
Not everyone's canvas is filling the window.
https://codepen.io/SeanMcBeth/pen/QWOoLNX
Throw a check in there to make sure the native dimensions actually did change so you don't needlessly redraw. Debounce it with setTimeout if you're super worried about people waggling their windows around or whatever.
Or does anyone here happen to know a way ?
I'm glad to have solved your mystery!
It still helps when you do your canvas at 2x rather than just at 1x. But if you're looking for best-fidelity rather than better-fidelity, duly noted.
It turns out it was very obviously exactly what you described. You basically have to double the resolution to get it to look decent on retina and 4k screens. Once I found this out I was over the moon!
(On a related note, colouring looks way off on the HTML5 target compared to native ones, and I spent an embarassing number of hours manually brute-forcing a shader to make everything look similar.
Oh, and sound sucks in the browser.
Oh, and Safari sucks. Seriously, it just sucks. The amount of hacks I put in place to workaround its egregious limitations, particularly regarding canvas operations is insane.)
https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende...
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.
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.
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.
So slow, that chrome falls back to software rendering, if you call getImageData 3 frames in a row.
(and does not even switch back to hardwarerendering if you stop calling it - last time I checked, was some months ago, so maybe that has improved)
I'm excited to try it out, as I do a kind of hacky hit detection using a hidden canvas, And reading the pixel color is certainly the bottleneck there
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);
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.
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.
The Chrome team's hubris is insulting to the web.
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
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".
https://html.spec.whatwg.org/multipage/canvas.html#the-canva...
It's all there. It's all official. That github page was just one part of reaching consensus. There's also TAG review:
https://github.com/w3ctag/design-reviews/issues/627
FWIW Mozilla and Safari signed off on all of these changes at some point in time somewhere, hence why it's allowed to be part of spec. There were some changes that were not allowed to be part of the new API because one of those two said no (like perspective transforms, conic curves).
For jdashg's concerns on that thread, 4x4 matrices were cancelled, and you can follow up with much more debate from all parties on roundRect and filters:
http://github.com/whatwg/html/pull/6763 https://github.com/whatwg/html/pull/6765
This is certainly not decided by fiat. Working to find consensus across browser implementers is just a ton of work.
> FWIW Mozilla and Safari signed off on all of these changes at some point in time
That's a relief then. Too often these days "it's official it's in the spec" as presented by Chrome is anything but.
> This is certainly not decided by fiat.
There are too many cases when it's decided unilaterally by Chrome.
This one made me laugh. Yes, WebGL excels at pixel manipulations but it is possible to write fast and efficient filters to work in the 2D canvas environment.
For a case-in-point, I struggled for a long time to find a decent, fast implementation of a gaussian blur filter for my canvas library. Then I stumbled upon a JS implementation[1] based on some very clever work done by Intel devs which blew all my previous attempts out of the water - so of course I stole it (even though I still don't understand the approach they take)[2].
> "Safari is the bad guy"
As much as Safari often brings me to despair, I do like the work they've recently done to add color space support in CSS. They haven't yet pushed the functionality over to the canvas element, but I live in hope. For now, I have to emulate the calculations to get them working for my library[3].
[1] - https://github.com/nodeca/glur/blob/master/index.js
[2] - https://scrawl-v8.rikweb.org.uk/docs/source/factory/filterEn...
https://web.archive.org/web/20110317025924/https://software....
It's not just about using SIMD instructions (they help), and laying out memory to optimize cache performance (which also helps), but most importantly that Gaussian blur is a "separable filter" that you can break up into a horizontal and vertical pass, each of which require a lot fewer memory references (on the order of just two times the number of pixels times the kernel size, instead of the number of pixels times the kernel size squared):
IIR Gaussian Blur Filter Implementation using Intel® Advanced Vector Extensions
>This white paper proposes an implementation for the Infinite Impulse Response (IIR) Gaussian blur filter [1] [2] [3] using Intel® Advanced Vector Extensions (Intel® AVX) instructions. [...]
>The IIR Gaussian blur filter applies equation (1) on each pixel through two sequential passes: The horizontal pass: This pass processes the input image left-to-right (row-wise), then right-to-left. The output of the left-to-right pass is added to the right-to-left pass.
>The vertical pass: Usually, the vertical pass processes the output from the horizontal pass top-to-bottom (column-wise), and then bottom-to-top. Accessing the input column-wise leads to a lot of cache blocks and impacts the performance of the filter. To avoid this, the horizontal pass transposes the output before writing to the output buffer. It makes the vertical pass similar to the horizontal pass and processes the intermediate output left-to-right, then right-to-left. The vertical pass again transposes the final output before writing the blurred image.
https://bartwronski.com/2020/02/03/separate-your-filters-svd...
>Separate your filters! Separability, SVD and low-rank approximation of 2D image processing filters Posted on February 3, 2020 by bartwronski
>In this blog post, I explore concepts around separable convolutional image filters: how can we check if a 2D filter (like convolution, blur, sharpening, feature detector) is separable, and how to compute separable approximations to any arbitrary 2D filter represented in a numerical / matrix form. I’m not covering any genuinely new research, but think it’s a really cool, fun, visual, interesting, and very practical topic, while being mostly unknown in the computer graphics community.
https://en.wikipedia.org/wiki/Gaussian_blur#Mathematics
>In addition to being circularly symmetric, the Gaussian blur can be applied to a two-dimensional image as two independent one-dimensional calculations, and so is termed a separable filter. That is, the effect of applying the two-dimensional matrix can also be achieved by applying a series of single-dimensional Gaussian matrices in the horizontal direction, then repeating the process in the vertical direction. In computational terms, this is a useful property, since the calculation can be performed in O(w_kernel w_image h_image) + O(h_kernel w_image h_image) time (where h is height and w is width; see Big O notation), as opposed to O(w_kernel h_kernel w_image h_image) for a non-separable kernel.
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/...
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
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$...
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
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/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/1652af38f76b1c4efb19...
line-color line-cap line-join dash-pattern
thickness
% dup -1 ne { .5 add } if % fudge outline width thicker
StrokeShape
Here's a description of Glenn's PostScript Distillery, which foreshadowed Acrobat Distiller.
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...
>From: [email protected] (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.
I'm pretty new to this - do you have an example of using bezier? And why is it preferred over arcTo?
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).
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();
}
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.