It makes sense. The great insight into all these kinds of screensavers is that you create a function that draws a line between two points, maybe with some amount of density and anti-aliasing. Then you create two random points, or four, and treat them like pong balls: They get a random velocity x,y and all they have to do is swap their x-1 or y-1 when they hit a side of the screen. Draw a line between them. And instead of refreshing the screen, just redraw over the last screen and fade any existing lit pixels. Boom, you have a fuzzy mustache screensaver.

How did that "fade any existing lit pixels" bit work? Do you just redraw the list N lines, fading in from black (to completely erase the oldest) to the full color of the newest?

In the windows one, there was no fade. It drew black lines on top of the old lines, and remembered a queue of about n=10 or so generations.

It's true, the windows one didn't fade. But the basic idea is that all the pixel values are just in an array. You draw the whole array to the screen on each frame. So each frame, you run through that array and divide all the color values by 2 for example, and any which are less than a certain threshold you just change to zero. Then you fill the specific points in the array where you want the next line to be drawn. The net effect is to fade out the old lines over time. You don't need to keep a list of past positions, or have any objects ;)

Got it. That makes sense but it’d never occurred to me to think about it before. I guess you could use an array N items long, with 4 values (x1,y1,x2,y2) in each element, and just keep a pointer to the oldest entry, incrementing it each time.

So, each ghost of a line is not stored at all. The moving line is stored as an object like you suggest. Each line has two Velocity-Point objects (which have 4 parameters: x,y location of the endpoint and x,y velocity of that point). So really a line can be viewed as an array with 8 values, which lives for the length of the whole program. I personally do kinda like object oriented code so it's helpful to think of the points and the velocity separately. But there's just one pointer to these values. The values are changed over time in that single Line object, and at each frame they're projected to the display buffer.

The display buffer is actually a flat 1D array which also lives through the whole program (mostly) where each 4 sequential values are the r,g,b,a for a single pixel. You don't ever need to copy that array unless you're doing something fancy with window resizing. A simple function translates any x,y coordinate pair (such as a point on a line) into the correct location in the flat array space, and you just modify that array as you go along. When you're done doing things to those values, you just overwrite the entire canvas with that 1D array in a single call.

In fact, the screen buffer array in this case was probably unnecessary, since <canvas> can easily let you get and set the values of individual pixels, draw lines, etc. But I wanted to do it in a flat array to reduce the number of draw calls to one per frame, and also to not overly bind my code to any particular display method.

I see, and thanks! Up next: star fields.

mmm... that sounds fun! I'll have to think about how that works. I say never look anything up until you've exhausted everything you can come up with ;)

Currently trying to implement the 'fuzzy' bit in this one:

https://gist.github.com/omnizach/886d9843b0fb176da2a7

I implemented this as an XScreensaver hack a few years back: https://github.com/Acedio/mystical

Was hoping it would be included in the distribution, but sadly never got a response D: