One of the things that’s plagued me since I’ve been doing creative coding is managing the code I use to create images and animations (or whatever else). Of course, standard source control management comes into it in a big way. I’ve been using git for ages. I remember having arguments with coworkers who refused to see how git was better than SVN (at least they had moved off of CVS). So yeah, you put your code in a repo and you check in your changes, etc.

But most source control workflows are really made for building applications. You decide on a feature, you make a branch, you do the work over a few hours or days or whatever, and you merge your code in. Or the same for a bug.

In creative coding though, the update/render cycle is a few orders of magnitude faster than that.

• Change a variable, render.
• Change it a bit more, render.
• Change another variable, render.
• Put the first one back to where it was, render.
• Ah! I like that one. Publish the image to twitter, or a website or wherever.
• Change some other variables around, render a bunch of times.
• Find another one you like, publish that image.
• Repeat several times.
• Done for the day, check in the code to git.

The problem is, tomorrow or next week or six months from now, you want to recreate that first image you published. What were the exact variable values you used to create it? Who knows? Even if you didn’t change the code, it might be nearly impossible to rediscover the exact parameters to recreate a specific image.

Git branches are too cumbersome for this fast workflow. You can make a new branch when you find some parameters you like, but as soon as you change some other values, that branch no longer represents that first image. There are ways to work around this, but again, it gets cumbersome. But I finally figured out a good solution, along with a custom shortcut that I’m really happy with: Tags.

A git tag is a permanent, unchanging reference to a specific point in time of your code base. Tag your code at a certain point and you can always get back to that exact point. It’s never going to change unless you delete the tag and create a new tag with the same name.

So, when you come up with an image that you want to save and publish, you do the following:

1. git add . to add all the changed files.
2. git commit -m <some message> to commit those changes.
3. git tag <some name> to create the tag to that exact commit.
4. git push to push it to the main repo (if you have one).
5. git push --tags to push the tags to the main repo.

All good, but that’s still five steps. Still a bit cumbersome. So I made a bash script that does all this in one shot:

#!/bin/bash

git add .
git commit -m $1
git tag $1
git push
git push --tags

I named this file tagit, made it executable (chmod +x tagit) and put it in my path. If you’re not totally up on shell syntax, $1 stands for the first argument given when the script is called. So now, when I want to save the state of my work, I jump to a shell and type tagit coolpicture or whatever tag name I want to give it.

This adds the files, commits them using coolpicture as a commit message, tags the commit with the same label and pushes to the main repo, and then pushes the tags to the main repo.

Now, six months from now when you want to see the settings you used for that cool picture, you just say git checkout coolpicture and there you are. Obviously, you want to name your tags something a bit more memorable. Some kind of timestamp or sequence is a good idea. I usually name the image or animation file the same as the tag name, so 210801a.png is the image that was created in the tag 210801a. You could even automate this if you wanted, to generate that image/tag name and rename the image when it creates the tag.

One other point that I know someone will ask.

Can’t you just say:

git push --tags

and ignore the

git push

?

You can if you want. It will push the current code that is in this tag to the main repo. But it will not push the current code in the current branch to that remote branch. So your remote master branch (or whatever branch you are on) will not line up with your local branch. But your tag will still be saved as expected. It’s up to you which behavior you want. Maybe you only want to push the tag, not commit to the branch at that point. Or maybe you want to save to the branch and the tag every time.

Also, you could change:

git push --tags

to:

git push origin $1

This will only push the specific tag you just created. There might be slight advantage to this in terms of speed. I suspect not. But, if you have other local tags hanging around that maybe you don’t want to push, you should go this route.

Anyway, use this script as is, or change it to fit your needs. Hopefully it saves you some time and frustration one day.

Earlier I talked about the new (and still experimental) filters that you can apply to the HTML Canvas’s 2d rendering context. One of the more powerful aspects of this is the ability to use external SVG filters in this workflow.

External SVG filters are applied using the url filter. It looks like this:

context.filter = "url(pathtofilter)";

It took quite a bit of frustration to figure out how to actually get these to work though. The documentation says that the path should point to an external XML document that contains an SVG filter. Again, all of this was borrowed from the CSS filter that works the same way. So let’s get an example of that working first.

SVG Filters in CSS

For this example, we’ll create a div and give it a style. The style will load in an external SVG document that has a filter defined in it. We’ll use the turbulence filter, which I believe uses some version of Perlin noise.

First the HTML:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <style>
      #filtered {
        filter: url(./filter.svg#turb);
        width: 600px;
        height: 600px;
      }
    </style>
  </head>
  <body>
    <div id="filtered"></div>
  </body>
</html>

The div is down at the bottom with an id of “filtered”. The style block creates the following filter:

filter: url(./filter.svg#turb);

This points to a file named filter.svg and a specific filter within that document with an id of turb. Next, lets look at that SVG document.

<svg
  version="1.1"
  xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  >
  <defs>
    <filter id="turb">
      <feTurbulence baseFrequency="0.01"/>
    </filter>
  </defs>
</svg>

This is a pretty bare bones SVG document. You see the filter there with the id of turb. This creates a turbulence filter with the line:

<feTurbulence baseFrequency="0.01"/>

That’s all. Run it and you get:

Now let’s see if we can do the same thing in a Canvas.

SVG Filters in Canvas

Per the documentation, we should just be able to do the same thing to load in an SVG filter and apply it to a 2d rendering context:

context.filter = "url(./filter.svg#turb)";

So let’s try it out. We’ll create a canvas right in the HTML doc:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
  </head>
  <body>
    <canvas id="canvas" width="600" height="600"></canvas>
    <script src="./main.js"></script>
  </body>
</html>

And in that script, we’ll get a reference to the canvas and context and try to apply the filter.

const canvas = document.getElementById("canvas");
const context = canvas.getContext("2d");

context.filter = "url(./filter.svg#turb)";
context.fillRect(0, 0, 100, 100);

When I run this, I get the black square that I drew, but no turbulence filter.

After a lot of digging in, I discovered that the context filter for external SVG docs does not seem to work in the same way. There is a workaround though – you add the SVG directly to the HTML of the main page. Our HTML now looks like this:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
  </head>
  <body>
  <svg
    version="1.1"
    xmlns="http://www.w3.org/2000/svg"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    >
  <defs>
    <filter id="turb">
      <feTurbulence baseFrequency="0.01"/>
    </filter>
  </defs>
</svg>
    <canvas id="canvas" width="600" height="600"></canvas>
    <script src="./main.js"></script>
  </body>
</html>

Now the script can load the filter directly by its id:

const canvas = document.getElementById("canvas");
const context = canvas.getContext("2d");

context.filter = "url(#turb)";

context.fillRect(0, 0, 100, 100);

And now we have some turbulence in our context!

But notice how it’s shifted over to the right. That’s because the SVG is now on the page. Even though it has no content, it’s taking up space. You can see it using the dev tools to highlight it:

There are probably a number of ways to handle this with CSS. Here’s how I dealt with it:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
  </head>
  <body>
  <svg
    style="width: 0; height: 0; position: absolute;"
    version="1.1"
    xmlns="http://www.w3.org/2000/svg"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    >
  <defs>
    <filter id="turb">
      <feTurbulence baseFrequency="0.01"/>
    </filter>
  </defs>
</svg>
    <canvas id="canvas" width="600" height="600"></canvas>
    <script src="./main.js"></script>
  </body>
</html>

This makes the width and height 0 and the absolute position makes sure it doesn’t affect the layout of anything around it. Problem solved.

More Weirdness

Note that I’m drawing a 100×100 black box into the context, but the turbulence filter just fills the entire canvas with its Perliny swirls. It seems that the black box is kind of useless. But if you remove it, you get … a blank canvas. So it seems the filter is applied only when something is drawn. In fact, it doesn’t matter what you draw. A single pixel will activate the filter and give you full canvas turbulence.

But then it gets more weirder. EVERY TIME you draw something, the filter is applied again. Trying this…

const canvas = document.getElementById("canvas");
const context = canvas.getContext("2d");

context.filter = "url(#turb)";

context.fillRect(0, 0, 100, 100);
context.fillRect(0, 0, 100, 100);
context.fillRect(0, 0, 100, 100);
context.fillRect(0, 0, 100, 100);
context.fillRect(0, 0, 100, 100);

Gives you this…

It applied the filter 5 times, making it a lot darker.

So if you want to apply a filter like this and then draw something on top of it, you have to kill the filter. This would seem pretty easy. But the first few things I tried did not work so well.

context.filter = "";
context.filter = null;
context.filter = "null";   // worth a shot!

None of these did anything. The previous filter remained active. Finally I found that this worked:

const canvas = document.getElementById("canvas");
const context = canvas.getContext("2d");

context.filter = "url(#turb)";

context.fillRect(0, 0, 100, 100);

context.filter = "url()";
context.fillRect(0, 0, 100, 100);

Applying an actual filter type with no parameters does the trick. This also works:

context.filter = "blur()";

There might be a better way to do this. I stopped when I found something that worked.

Summary

Applying SVG filters to a context is pretty powerful. I’ll be checking out other available filter types. Here’s a list:

• <feBlend>
• <feColorMatrix>
• <feComponentTransfer>
• <feComposite>
• <feConvolveMatrix>
• <feDiffuseLighting>
• <feDisplacementMap>
• <feFlood>
• <feGaussianBlur>
• <feImage>
• <feMerge>
• <feMorphology>
• <feOffset>
• <feSpecularLighting>
• <feTile>
• <feTurbulence>
• <feDistantLight>
• <fePointLight>
• <feSpotLight>

And you can combine several of these filters into your own custom filter that you apply to a canvas. It gets really powerful. I’ll probably be playing around with this more in the near future and will share my results.

At the same time, the workflow for creating and applying filters to a canvas rendering context is still pretty janky. I think the CSS flow is pretty solid, but as I said in my last post, the canvas feature is still experimental.

Resources

If you want to find out more about creating and combining SVG filters into neat patterns, here are some links:

https://css-tricks.com/creating-patterns-with-svg-filters/

https://www.linkedin.com/pulse/26-images-you-wont-believe-were-created-only-svg-bence-szab%C3%B3/

https://www.smashingmagazine.com/2015/05/why-the-svg-filter-is-awesome/

All of these techniques should work pretty well in native SVG elements as well as CSS, and theoretically in canvas too, with a bit of effort.

For the past couple of years or so, I’ve focused mainly on creating images and animations with Go and my own Go library, blgo, that uses CairoGraphics bindings (my own fork of go-cairo).

When I started creating MiniComps, it was an opportunity to get back into JavaScript-based content creation using HTML’s Canvas and its 2d rendering context. The canvas drawing API is pretty much the same as Cairo, but it’s been nice getting back into interactive, web-based pieces – not so easy in Go/Cairo. I made an updated version of my bitlib library for 2021, bljs, and if you’ve been on this blog or follow me on Twitter, you’ve seen some of the stuff I’ve been doing with it.

But recently I started looking at the documentation for Canvas and the 2d rendering context and found some pretty interesting things that weren’t there last time I looked.

Filters!

This is super powerful. Filters are a cool new way to change the look of your canvas drawings. The context now has a filter property, which is a string and allows you to add one or more defined filters to it. For example, to add a blur:

context.filter = "blur(8px)";

To add multiple filters, just add them to the string:

context.filter = "blur(8px) contrast(50%) sepia(20%)";

Here’s a demo that allows you to play with a handful of the filters available:

Source

Here are the full list of filters available:

• blur
• brightness
• contrast
• drop-shadow
• grayscale
• hue-rotate
• invert
• opacity
• saturate
• sepia

If you look through these, you’ll realize these are basically the same as already existing CSS filters. In fact, you could already do some of these same affects by adding a filter style to the canvas element itself. For example:

canvas.style = "filter: invert(100%)";

Here’s another demo using this method:

Source

So what’s the difference?

Actually, a pretty big difference. When you apply a filter to a 2d rendering context, it does NOT change the existing content. It will only affect anything drawn after the point when the filter was applied. If you take a look at the code in the first example, I need to clear the canvas and redraw all the content in order to have the filter take place. Whereas applying the filter to the canvas affects the whole element in real time. No need to redraw the content. This also means that using the CSS filter on the canvas element is non-destructive. Using a blur, for example, on the context means the subsequently drawn pixels are permanently blurred.

Also, because the CSS filters apply to the whole element, the blur filter will blur the element beyond its boundaries, whereas the context filter only applies to the pixels inside the canvas. (You can probably change that for the CSS version by applying other styles, such as overflow.)

So far it seems like the CSS version has a lot of the advantages. But the context version does have some plus points. If you want to export the blurred or otherwise filtered image and save it somewhere, you’ll need to have the filters applied to the image in the context, not just the canvas element.

Also, applying filters to the context means you can selectively turn them off and on or change their parameters for each shape you draw. Here’s an example:

Source

Here, the red square is drawn with no filter, the black one with a 10px blur, and the blue with a 0px blur. You couldn’t do that directly with a CSS filter.

Experimental

It’s worth noting that these are experimental features. They may not work in all browsers. Definitely WON’T work as of this writing in Safari or IE, and may change in the future.

SVG Filters

One of the more powerful aspects of being able to use filters is that you are not limited to the fairly basic assortment of built-in filters. You can create extremely complex and powerful filters using SVG and then apply those directly to your canvas context. I’ll discuss how to do that in another article.

Resources

https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/filter

https://developer.mozilla.org/en-US/docs/Web/CSS/filter

Sure, why not, right?

One of the things I was trying to accomplish with the shaky drawing from my last post was to give the idea of hand-drawn lines. By adding in a bit of random variance, lines and shapes can seem like they are drawn by a human rather than perfectly rendered by a computer.

But at some point I was actually sketching something by hand and realized another big difference between computer drawing and human sketching. Very often when a person is sketching, rather than boldly drawing what they hope is a straight line from point A to B, they will instead make a number of very light lines that roughly go between the two points. You’ve seen it, you’ve done it, you know what I mean. So let’s replicate that.

The idea is that when we want to draw a line from x0, y0 to x1, y1 for example, we’ll actually draw multiple lines – not exactly to those to points, but from somewhere around the first point, to somewhere around the second one.

In this case, I’m going to dive right into a function. This was my first attempt:

function sketchLine(context, x0, y0, x1, y1, count, rand) {
  context.beginPath();
  for (let i = 0; i < count; i++) {
    let x = x0 + Math.random() * rand - rand / 2;
    let y = y0 + Math.random() * rand - rand / 2;
    context.moveTo(x, y);

    x = x1 + Math.random() * rand - rand / 2;
    y = y1 + Math.random() * rand - rand / 2;
    context.lineTo(x, y);
  }
  context.stroke();
}

We can then call this like so:

context.lineWidth = 0.2;
sketchLine(context, 100, 100, 700, 700, 5, 20);

Note that I set the line width down to 0.2 to make very light lines. We’ll let the multiple light lines build up to create the idea of a sketch, the same way you would do it by hand. So this will draw 5 lines with a variance of up to 10 pixels in any direction from the starting and ending points. The result:

Not that great, to be honest. The lines vary a bit, but they are still too uniform. I can bump up the randomness to, say, 50, but that looks even less like what a real person would sketch.

The thing with sketching, particularly in longer lines, is that you don’t always sketch the entire length of the line on each stroke. You might start around the first point and stroke maybe half way to the other point. And then you might stroke the middle third of the distance between them, and then something closer to the ending point. You’d do a bunch of strokes with varying start and end distances. Well, we can do something like that too.

function sketchLine(context, x0, y0, x1, y1, count, rand) {
  const dx = x1 - x0;
  const dy = y1 - y0;

  context.beginPath();
  for (let i = 0; i < count; i++) {
    let t0 = Math.random() * 0.5;
    let t1 = Math.random() * 0.5 + 0.5;
    
    let x = x0 + dx * t0 + Math.random() * rand - rand / 2;
    let y = y0 + dy * t0 + Math.random() * rand - rand / 2;
    context.moveTo(x, y);

    x = x0 + dx * t1 + Math.random() * rand - rand / 2;
    y = y0 + dy * t1 + Math.random() * rand - rand / 2;
    context.lineTo(x, y);
  }
  context.stroke();
}

This should look somewhat familiar if you’ve followed along with the other two posts in this series. First I get length of the line on the x and y axes – dx and dy. In the loop, I create a t value between 0 and 1. In this case, I create two of these – t0 and t1 – one for the start of the line and one for the end. t0 will range from 0.0 to 0.5 and t1 will go from 0.5 to 1.0. This should give us a random assortment of lines – some from very near the start point to very near the end point, some more in the first part of the line, some in the middle and some more near the end. Calling this again with:

context.lineWidth = 0.2;
sketchLine(context, 100, 100, 700, 700, 5, 20);

We get this image:

That’s something I could almost start to believe was done by hand. Let’s do a rectangle function!

function sketchRect(context, x, y, w, h, count, rand) {
  sketchLine(context, x, y, x + w, y, count, rand);
  sketchLine(context, x + w, y, x + w, y + h, count, rand);
  sketchLine(context, x + w, y + h, x, y + h, count, rand);
  sketchLine(context, x, y + h, x, y, count, rand);
}

Obviously, I just copied and pasted the shakyRect from the previous post and changed the method names and parameters. So let’s call this with:

context.lineWidth = 0.2;
sketchRect(context, 100, 100, 600, 600, 5, 20);

Pretty cool, but this brings up an issue we couldn’t immediately see when drawing a single line. All too often, the lines don’t reach all the way to those starting or ending points. Too many are falling right in the middle. We can shift our random parameters a bit to make up for that.

function sketchLine(context, x0, y0, x1, y1, count, rand) {
  const dx = x1 - x0;
  const dy = y1 - y0;

  context.beginPath();
  for (let i = 0; i < count; i++) {
    let t0 = Math.random() * 0.4 - 0.1;
    let t1 = Math.random() * 0.4 + 0.7;
    
    let x = x0 + dx * t0 + Math.random() * rand - rand / 2;
    let y = y0 + dy * t0 + Math.random() * rand - rand / 2;
    context.moveTo(x, y);

    x = x0 + dx * t1 + Math.random() * rand - rand / 2;
    y = y0 + dy * t1 + Math.random() * rand - rand / 2;
    context.lineTo(x, y);
  }
  context.stroke();
}

Now, t0 will range from -0.1 to +0.3, and t1 will go from 0.7 to 1.1. This makes it more likely that some lines will make it closer to one of the points, and may even overshoot it a bit, which is just what you’d do by hand. The results of this change:

Not bad, in my opinion. You’ll still have some rectangles with open corners, but not as often as before. Here’s one with a count of 20 and a rand of 40:

Finally, just for the heck of it, I combined the shaky and sketchy techniques with this function:

function sketchLine(context, x0, y0, x1, y1, count, rand) {
  const dx = x1 - x0;
  const dy = y1 - y0;

  context.beginPath();
  for (let i = 0; i < count; i++) {
    let t0 = Math.random() * 0.4 - 0.1;
    let t1 = Math.random() * 0.4 + 0.7;
    
    let xA = x0 + dx * t0 + Math.random() * rand - rand / 2;
    let yA = y0 + dy * t0 + Math.random() * rand - rand / 2;
    let xB = x0 + dx * t1 + Math.random() * rand - rand / 2;
    let yB = y0 + dy * t1 + Math.random() * rand - rand / 2;
    shakyLine(context, xA, yA, xB, yB, 20, 2);
  }
  context.stroke();
}

Here, I calculated the start and end points of each sketched line and rather than using moveTo and lineTo I called the shakyLine function from my last post. I hard coded it with a res of 20 and a rand of 2, which makes it just a little bit less than a perfectly straight line and possibly a little bit more like something hand drawn. Called with:

context.lineWidth = 0.2;
sketchRect(context, 100, 100, 600, 600, 10, 20);

it gives us:

Even that might be too much shake, but you can easily make it more subtle.

Here’s one final example. If this doesn’t look hand sketched, I don’t know what does.

Well, that’s that. I don’t have a ready-made library to share with you on this one, but hopefully you’ll find this useful or at least inspiring.

The rest of the How to Draw a Line series:

1. How to Draw a Line

2. More Ways to Draw a Line

3. Yet Another Way to Draw Lines

In the last post, I discussed an alternate way of rendering lines, that could give a glitchy look, painterly look, or many other looks based on what parameters you used. In this post, I’ll discuss another way to draw lines.

The theme to these posts is that using moveTo / drawTo is fine but gives you clinical, antiseptic, perfect straight lines (or curves). And sometimes it’s nice to shake things up a bit. In fact, shaking things up is exactly what we’re going to do here today.

I’m going to start with something very similar to one of the earlier examples in the last post, but instead of drawing individual pixels along the length of the line, I’m going to draw short line segments.

const dx = x1 - x0;
const dy = y1 - y0;
const dist = Math.sqrt(dx * dx + dy * dy);
const res = 10;

context.beginPath();
context.moveTo(x0, y0);

for (let i = res; i < dist; i += res) {
  let t = i / dist;
  let x = x0 + dx * t;
  let y = y0 + dy * t;
  context.lineTo(x, y);
}
context.lineTo(x1, y1);
context.stroke()

Like before, I’m starting with two points defined by x0, y0 and x1, y1. And I’ve defined a res variable that dictates the length of those intermediate segments. Note that I moveTo the first point and set i equal to res to initialize the loop, and then lineTo the last point. This ensures that the start and end of the line remain constant (which will be important later). Otherwise, things should be familiar here if you read the previous post. Here’s what this gives us:

It’s exactly what you’d get if you just drew a line from the first to last point. So big deal. But now that we have these intermediate points, we can shake things up as promised.

I’ll just randomly shift each x, y point a bit before drawing to it. (Just showing the for loop here:

for (let i = res; i < dist; i += res) {
  let t = i / dist;
  let x = x0 + dx * t;
  let y = y0 + dy * t;
  x += Math.random() * 4 - 2;
  y += Math.random() * 4 - 2;
  context.lineTo(x, y);
}

This puts each x, y location somewhere from -2 to +2 on each axis. And gives us this:

I then put this all into a function to make it easily reusable:

function shakyLine(context, x0, y0, x1, y1, res, rand) {
  const dx = x1 - x0;
  const dy = y1 - y0;
  const dist = Math.sqrt(dx * dx + dy * dy);

  context.beginPath();
  context.moveTo(x0, y0);

  for (let i = res; i < dist; i += res) {
    let t = i / dist;
    let x = x0 + dx * t;
    let y = y0 + dy * t;
    x += Math.random() * rand - rand / 2;
    y += Math.random() * rand - rand / 2;
    context.lineTo(x, y);
  }
  context.lineTo(x1, y1);
  context.stroke();
}

Now I can just call it like so:

shakyLine(context, 100, 100, 700, 700, 10, 10);

And it creates a line like this:

Note that the random factor is 10 here, so it’s a lot more shaky than the earlier example. Note that the res and rand parameters both contribute in different ways to the shakiness of the line. So if I move res down to 5, but keep rand at 10, we get something more shaky, but in a tight way.

But here, I’ve bumped both res and rand up significantly:

shakyLine(context, 100, 100, 700, 700, 50, 40);

This gives us a line that varies a lot more, but because each segment is longer, it’s more of a chunky random shake.

So you can play these two parameters off each other to get various effects.

The next thing to do is create a shakyRect function. It looks like this:

function shakyRect(context, x, y, w, h, res, rand) {
  shakyLine(context, x, y, x + w, y, res, rand);
  shakyLine(context, x + w, y, x + w, y + h, res, rand);
  shakyLine(context, x + w, y + h, x, y + h, res, rand);
  shakyLine(context, x, y + h, x, y, res, rand);
}

As mentioned before, the fact that each line starts and ends on a non-shaky point means that the rectangle will be continuous. You can call it like this:

shakyRect(context, 100, 100, 600, 600, 10, 10);

And get a rectangle like this:

To show how res and rand relate, I made this for loop that draws a bunch of squares on the canvas. res increases from left to right and rand increases from top to bottom. It gives you a good idea of the different effects you can create.

for (let y = 20; y < 730; y += 70) {
  for (let x = 20; x < 730; x += 70) {
    shakyRect(context, x, y, 50, 50, x/730 * 10, y/730 * 10);
  }
}

Now, this rectangle function isn’t the best because it doesn’t support fills, but you can probably work up a better solution. You might also want to create functions for drawing other shaky shapes.

Or, maybe you just want a drop in library you can use. I created a whole JavaScript shaky library about 7 years ago. I can’t guarantee how well it has stood the test of time. There are undoubtedly some best practices in there that could be updated. But the core code should be good enough to work out things for yourself. It supports not only lines and rectangles, but circles, arcs, quadratic curves, bezier curves, and arcs. And as of this writing, it has 101 stars, which is kind of neat!

https://github.com/bit101/shaky

All the posts in the How to Draw a Line series:

1. How to Draw a Line

2. More Ways to Draw a Line

3. Yet Another Way to Draw Lines