It's always been you, Canvas2D(developer.chrome.com)

  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`).

    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

    line-color line-cap line-join dash-pattern
    thickness
    % dup -1 ne { .5 add } if % fudge outline width thicker
    StrokeShape

  const color = [254, 134, 29];
  ctx.fillStyle = `rgb(${color})`;
  ctx.fillStyle = `rgba(${color},0.5)`; // I use this one pretty often

    location.href = location.href;

    canvas.width ^= 0;