Is pixel-level writing supported?

Archived
1

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.

2

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.

3

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.

4

How did this project go?

5

Thanks, cocotower. Roku is not going to support this and your solution is the only one either of us imagines. I chose to implement BMP file as the means. It was trivial to write a “fixed” BMP header to describe a raw ARGB file and then write that header and then the actual byte array into a file and read it back via DrawObject. Since it’s all solid state memory, it’s fast and, internally, is probably just a memory blit during i/o.

Thanks for the help.

6

Yep, there are more ways than one to skin a cat(fish).