I want to write a screensaver that displays animated blends/gradients. The algorithms for these would generate sequential pixels in scanline order; I.e, left-to-right, top-to-bottom. Generally, however, it would be useful to have a more general, random access functionality.
I see discussions back as far as 2014 requesting pixel-level access, but nothing in the current, on-line documentation that supports this. There’s a GetByteArray(), but no corresponding SetByteArray().
I suppose I could investigate drawing a hundred thousand, 1 pixel long lines, or 720, 1 x 1280 pixel sprites or write it all out to a PNG file and then draw the file, etc., but I don’t think any brute force hack I can think of will be efficient enough for animation.
Any help, guidance or insight would be greatly be greatly appreciated.
There's a typical way of doing stuff like this when an API doesn't allow framebuffer access. I haven't tried it yet it with Roku yet but essentally you create a large bitmap image in memory and display it or update whatever object it's bound to. For Roku I guess it would need to be in PNG format. It's probably even faster than direct screen memory access. I do something similar but in raw bitmap format for an Android app I wrote. The framerate is pretty fast because I write 32-bit values for each pixel in aRGB format.
Thanks for the reply. I also came to the conclusion that going through the filesystem is the only way to get pixel data into a bitmap/screen.
FYI: PNG was not an option, as you can only write to PNG from a Bitmap, not a ByteArray. I went with BMP: simple header, no compression. But you gotta deal with the BRG vs RGB issue, though. The Pixel Masks in the BMP header are ignored by Roku.