Currently it writes pixels byte by byte when we could be doing it by 32-bit pixels at a time. In unrelated artificial tests this gives me a ~585% speed up (from an "unplayable" 11 FPS to a playable 60 FPS) just filling a canvas.
Note that this makes it endian-dependent. Honestly I don't forsee a lot of big endian devices using this, but we could always detect endianness and use a branch (ideally by swapping out which makePixel(r, g, b) -> uint32 function we use.)
We should probably implement the native color map lookup table generation and pre-compute the 32-bit values instead of RGB. (#17)
Currently it writes pixels byte by byte when we could be doing it by 32-bit pixels at a time. In unrelated artificial tests this gives me a ~585% speed up (from an "unplayable" 11 FPS to a playable 60 FPS) just filling a canvas.
Note that this makes it endian-dependent. Honestly I don't forsee a lot of big endian devices using this, but we could always detect endianness and use a branch (ideally by swapping out which
makePixel(r, g, b) -> uint32function we use.)We should probably implement the native color map lookup table generation and pre-compute the 32-bit values instead of RGB. (#17)