Refactor 2022 #39

568.jpg

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.

Refactor 2022 #38

567.jpg

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.

Refactor 2022 #37

566.jpg

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.

Refactor 2022 #36

565.jpg

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.