Little squares.

Computer generated pictures could be pixel-first or object-first. Yes, I made up those terms. Fractals are pixel-first. Pick a pixel, run the fractal calculation for the pixel to get a color, color the pixel, then move on to the next pixel.

This image consists of many small squares, and is drawn object-first. Pick a square, compute which pixels are on the square, color those pixels with the color of the selected square, and then move on to the next square.

In theory, one could draw the image either way. The pixel-first method would pick a pixel, test each square to determine if it contains the pixel. Determine a color based on those squares, color the pixel. Then move on to the next pixel.

Object-first seems more natural, it is how I would paint this without a computer. Also the algorithm seem more intuitive.

Object-first is an easy choice with many small squares. There are many squares, each affecting just a few pixels. A pixel-first approach would result in many empty tests. Each pixel is tested against each square. Almost all of those tests are false, resulting in a do-nothing step.

Of course the key is that for the object, in this case a square, there is an efficient way to say in bulk which pixels are covered by the square. All those do-nothing, not-in-the-square tests are avoided.

My program was initially designed for fractals, and so it has a strong pixel-first bias. I do jump back and forth between the two methods, but within the program they are not symmetric. Things in the program are optimized for pixel-first, object-first tasks seem like a kludge. So for the refactor I am trying to balance things out and make it easy to choose between pixel-first or object-first methods.

The little squares are laid out along Lissajous curves

Three more with little squares along Lissajous curves, without commentary.