It has been several days since the last blog post.

I have something specific that I have been struggling to create. I decided to write in this blog about those struggles, and found it difficult to describe what I was trying to create. Perhaps that indicates that my specific intent is not very well defined after all, which could explain why the implementation is difficult.

Perhaps I will write more on this not-very-specific thing later. Let's fast forward a few days. Somewhere in the process I decided I needed to extract a background or secondary feature in the "big idea", and work on it separately.

So, here is a fuzzy random background pattern.

Even though these pieces are the result of software development / testing, I put in more effort than a simple test requires. They deserve a stand-alone collection rather than being just filed under "Refactor 2022".

I have some favorite default color palettes, blue/brown, black/white, rainbow. Typically I work with one of these default color sets, and focus on shapes and arrangements. Often the process stops there, and the default palette becomes the final palette. Reworking the colors seems like a lot of effort, the arrangement is the main thing, and I am usually eager to start on the next picture. When I make an effort to redo the design in different colors, I tend to use bright, saturated colors. Subtle colors takes more patience

So I am trying out some new (for me) color sets. Colorful, but not dominated by fully saturated colors. I hope to build a bigger tool box of starting color sets, then the final design step should be small tweaks rather than a full reset.

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

The little squares are laid out along Lissajous curves

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.

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.