"squirreltown" wrote:
I tried using base64 and it was NOT a help, it consistently took maybe 15% longer to send the string on my test image. It would make sense since the hex string always uses 8 characters to describe a pixel, the base64 sometimes uses only 4, but more often than not uses 10.
You're right. I don't know what I was thinking when I used it earlier. I was getting binary and character data mixed up in my brain in another solution I was playing around with (not the one I posted). [I wasn't sure the Roku and the server would be able to handle POSTing a big chunk of binary data with an Http Content-Type of application/x-www-form-urlencoded, but apparently they can].
It might have helped in your earlier attempt where it looked like you were representing a 32-bit color in its hex form as ASCII characters: "FF0000FF", which would take up 8 x 8 = 64 bits, versus encoding the 32-bit value in Base-64, which would take 32 / 6 x 8 = 42.66666 bits. However, now that you're using straight binary data, you're only using 32 bits per pixel, so no need to encode.
What might help though would be to use some kind of compression algorithm at the Roku end, replacing groups of the same pixel value with a pixel value and a count, for example. If your images have repeating colors you may be able to end up transferring much less data, which is where your bottleneck is likely to be.
