Efficiently moving things around in zig-zag Graphics buffer visualized w/ 24/32 bpp displays / neopixel strings

Recently played around with neopixels that I control w/ an Espruino Graphics object (see x by y w/ 24 bpp Graphics buffer visualized with neopixel string).

var c=`
// Get some speed for odd graphics buffer manipulation, such as for running
// text... moving rainbows,... (odd zig-zag... and 'pull out' into other buffers)
// On PICO w/ dev=false profiled on 20 cols x 7 rows w/ 133 of 140 neopixels
// and col counts: ccc = 1 | 9 | 18 --> 0.326 | 0.357 | 0.388 [ms]
// Development Example - set dev = true (in line 35):
//       copy left - destination same as or different from source
// 
//
// 7 x 4 24bpp graphics buffer in zigo-zag driving a 28 neopixels string
//
//        00       01       02       03       04       05       06
//       .-----------------.        .-----------------.
// 00    |00 01 02|03 04 05|06 07 08|09 10 11|12 13 14|15 16 17|18 19 20 --.
//       |                 |        |                 |                    |
// 01 .--|41 40 39|38 37 36|35 34 33|32 31 30|29 28 27|26 25 24|23 22 21 <-'
//    |  |                 | <----- |                 |
// 02 '->|42 43 44|45 46 47|48 49 50|51 52 53|54 55 56|57 58 59|60 61 62 --.
//       |                 |        |                 |                    |
// 03    |83 82 81|80 79 78|77 76 75|74 73 72|71 70 69|68 67 66|65 64 63 <-'
//       '-----------------'        '-----------------'
`;

Especially in a x-y-panel arrangement of neopixels, the Espruino Graphics object is for many things superior to manipulating a buffer directly. Graphics object is even able to handle the zig-zag storage arrangement which allows minimal hardware effort to place wire a neopixels string onto a panel (no 'fly-back' wire).

Drawback of x-y-panel arrangement though creates some challenges when trying to move things around, such as running text, walking rainbow, etc. Of course, redrawing with different origin works to some extent; but besides the slow-down, jumpiness and not being able to begin text outside (at negative x or column) of the display buffer (loosing space), redrawing is not an option.

This pushed me to venture into integrated / inline C... and I really like it... could have used that earlier when fooling around with displays to speed up operations on scattered memory locations.

Speed is what I'm looking for... I copy 133 of 140 neopixels in less than 0.4[ms]. This is not only helpful on Espruino boards - to get to better neopixel refresh rates, but on all the ...strapped ESP-8266 that have to go to tend to WiFi 'at once in a while'... and application processing has to fit into the breaks in between; otherwise, as we know, ESP8266 crashes (with infinite reboot loop). Times on ESP8266 may even look better, because the processor runs faster, I recall... I don't know whether the serial flash messes with the speed... but it's worth a try... Who is a taker for that test?

A nice extra was that I need to pass at least 8 parameters... 4 are supported... Solution is to put all numeric and pointer args into an Uint32Array and have just one single argument to pass... With that mastered, just anything that would be needed for context can be passed from JS to C.

Having to use a parameter array makes calling the C function directly in the application code quite verbose and cumbersome. Therefore a wrapper around the call provides many goodies:

• Destination buffer can be same as source buffer, but does not have to (for in-place, only left and up copy is handled so far).
  
• Prepare an argument block and reuse it on the same buffer(s) with just changing the copying parameters, which are column and row counts. All the other setting stay the same for the same buffer(s).
  
• Do some checking of argument validity, such as that buffers must be flat strings (implemented), stay within buffer boundaries (not implemented yet).
  
• Hiding the pixel to byte translating numbers
  
• Hiding the E.getAddressOf(...) for the buffer pointers
  
• Have a place to pass back from C / to stick the return value (and error values negatively) to: args[0]
  
  

Next is to make it work for non-zig-zag and safe for in-place copying / shifting for all directions an (reasonable) combinations there of... (that wii switches the copy begins and ends around).

Here the code:

...sorry, textarea size on forum initial post exceeded... post is cropped... see next... post #2.