Driving LED matrix with shift registers such as 74HC595

Indeed - but it has not to be THAT inefficient: even number of columns makes life already easy, and with increased number of columns, memory efficiency for odd number of columns approaches 75% (starting out from 37.5%). The goal is to have a configurable piece of scan code...

The greater issue is the targeted hardware, which - when you look at the pitched code example at their site - requires to send first all red bits of a row, then all greens, and then all blues... This *IS* 'The Blues' for programming. I do not know what their motivation was to wire up the hardware this way. Any color display controller I know of stores the information pixel-bundled and NOT color-bundled.

To cater to that hardware wiring, I'm thinking of introducing compiled for the scan or add .flip() technique in a compiled function for fast bit fiddling (Pick all red bits from all row bits and put them together into a row write buffer, then all greens, and then all greens and finally all blues and then send the row write buffer... all this bit adding/shift/oring with reduced CPU cycles). First is better because transparent to the application, latter gives at least power to the application to run the bit fiddling only after multiple updates of the Graphics buffer that compose one or more logical (complete) updates (like a display transaction).