This is still on the agenda, I deem that it most likely will happen, but I don’t know when. 2014 is an extremely busy year.
- Joel
Thanks, appreciate the update!
Hi Joel,
is there any update on this requirement, i am in a similar situation where we have multiple icons to be rendered on gridscreen, all have same background with only change in the text.
it would be quite helpful if there is any progress on this.
Thanks,
Ramakanth.G
We generally cannot talk about new features before they are released and documented.
- Joel
Bump!
Any update on this one, Roku*?
Probably best to add a roBitmap (ifDraw2D formally and better) method saveAsPNG(filePath as String) as Boolean
PNG because of faster compression and preserving transparency. And btw does not have to bother compressing, since main intent is this being loadable by ro- and sg-components. I believe Roku already uses libpng, so implementing this would be 1 man-day’s work. Set compression to 0, just RGBA (no grayscale, no indexed, no palettes), no interlacing, no troubles - it’s about avoiding temptation of feature creep and “just do it”. Optional parameters can always be added some other year.
A code even be written from scratch with sole purpose of quickly writing uncompressed PNG (see http://stackoverflow.com/a/8113783/226086 for format discussion, it’s about avoiding filtering and generating ‘deflate’ in store-mode) - and somebody i remember did it years ago in B/S - but it was way, way too slow to use.
“EnTerr” wrote:
Bump!
Any update on this one, Roku*?Probably best to add a roBitmap (ifDraw2D formally and better) method saveAsPNG(filePath as String) as Boolean
(PNG because of faster compression and preserving transparency. And btw the first iteration can be an oddball, no problema - e.g. no compression, as long as it can be loaded by components)
[upload|tqUw3EkqhQUYMjdNVm/5kg==]
You can use ifDraw2D getPng for this:
https://sdkdocs.roku.com/display/sdkdoc/ifDraw2D#ifDraw2D-GetPng(xasInteger,yasInteger,widthasInteger,heightasInteger)asObject
“RokuKC” wrote:
You can use ifDraw2D getPng for this:
https://sdkdocs.roku.com/display/sdkdoc/ifDraw2D#ifDraw2D-GetPng(xasInteger,yasInteger,widthasInteger,heightasInteger)asObject
Sweet!!!
Just documented but seems valid since fw 7.0 (“retroactively”).
This can liven up both ro-channels and sg-channels. E.g. player app can prep posters while browsing media on USB/NAS drive
“EnTerr” wrote:
“RokuKC” wrote:
You can use ifDraw2D getPng for this:
https://sdkdocs.roku.com/display/sdkdoc/ifDraw2D#ifDraw2D-GetPng(xasInteger,yasInteger,widthasInteger,heightasInteger)asObject
Sweet!!!
Just documented but seems valid since fw 7.0 (“retroactively”).This can liven up both ro-channels and sg-channels. E.g. player app can prep posters while browsing media on USB/NAS drive
It works great. Now, if we can just compress it so I could send it somewhere ( err..conveniently). 
Add a file type to AsyncPostFromFile? ( it already works, it just sends it uncompressed)
“squirreltown” wrote:
It works great. Now, if we can just compress it so I could send it somewhere ( err..conveniently).
Add a file type to AsyncPostFromFile? ( it already works, it just sends it uncompressed)no, not there. Compression would have to be optional param to getPng(). I recon, very low priority if ever. The real important part is to be able to generate temp images ASAP (speed vs compression ratio are inversely related)
“squirreltown” wrote:
It works great. Now, if we can just compress it so I could send it somewhere ( err..conveniently).
Add a file type to AsyncPostFromFile? ( it already works, it just sends it uncompressed)
The PNG pixel data is deflate/zlib compressed using a default setting.
While gzipping the post would no doubt squeeze the file size additionally, I wouldn’t expect it to be that significant in the grand scheme of things.
But I suppose it might depend on what type of images you have and what you are doing with them. 
“RokuKC” wrote:
“squirreltown” wrote:
It works great. Now, if we can just compress it so I could send it somewhere ( err..conveniently).
Add a file type to AsyncPostFromFile? ( it already works, it just sends it uncompressed)The PNG pixel data is deflate/zlib compressed using a default setting.
While gzipping the post would no doubt squeeze the file size additionally, I wouldn’t expect it to be that significant in the grand scheme of things.
But I suppose it might depend on what type of images you have and what you are doing with them.
Yes, I’ve noticed there is (very reasonable) compression, but sending the file takes the same amount of time as sending a byte array, it’s not like one would expect for an “attachment”.
I’ve been doing this awhile, to get what are essentially screen caps out of the box. It takes about 5-6 seconds to send a 1.2mb-ish file in tmp:/ to a local NAS for processing.
Glad to have the feature though, very useful for me.
“squirreltown” wrote:
Yes, I’ve noticed there is (very reasonable) compression, but sending the file takes the same amount of time as sending a byte array, it’s not like one would expect for an “attachment”.
Sorry, I don’t understand what you mean by this. If a 1 MB bitmap compresses to a 200 KB jpeg, then sending it (uncompressed) will take the same amount of time as sending a 200 KB byte array. 200 KB is 200 KB. If you compress a 200 KB file, it MAY get smaller, depending on the contents. A text file with a lot of redundancy will compress very small, but a file of random data with little redundancy won’t compress much at all (and may even get bigger). A jpeg file is already compressed, so it can’t be compressed much further. Perhaps I misunderstood what you were saying.
–Mark
“RokuMarkn” wrote:
“squirreltown” wrote:
Yes, I’ve noticed there is (very reasonable) compression, but sending the file takes the same amount of time as sending a byte array, it’s not like one would expect for an “attachment”.Sorry, I don’t understand what you mean by this.
He meant that in his personal observation, uploading a snapshot taken with GetPng() took about as much time as one done with GetByteArray(). Presumably transferred to a local NAS by unknown means (http PUT?).
@squirreltown , try to be more systematic about such things -
(a) measure time, sizes and
(b) use “divide & conquer” approach, e.g. include pre-saved PNG in your bundle and try uploading that instead of GetPng() one - my money are on it will take the same time. Then we can think what causes delay to your NAS upload
“RokuKC” wrote:
The PNG pixel data is deflate/zlib compressed using a default setting.
While gzipping the post would no doubt squeeze the file size additionally, I wouldn’t expect it to be that significant in the grand scheme of things.
But I suppose it might depend on what type of images you have and what you are doing with them.
I remember once upon a time asking why PNG was specifically excluded from Roku makefile https://forums.roku.com/viewtopic.php?p=442441#p442444
Apparently can’t squeeze blood from a turnip
But RokuKC - is “default setting” also the fastest?
Speaking in practical terms, not OCD ones. (e.g. 10-20% is peanuts but 2x is BFD)
PS. 2600ms on a Roku3… way slow. Seems will have to thread carefully
“EnTerr” wrote:
He meant that in his personal observation, uploading a snapshot taken with GetPng() took about as much time as one done with GetByteArray(). Presumably transferred to a local NAS by unknown means (http PUT?).
Yes. Sending the result of GetPNG() or GetByteArray() to a PHP file on a local NAS which creates a jpeg/png file.
lets say I’m capturing a 1480 x 920 file. It takes no time to do GetPng(), then about 5-6 seconds while it gets sent via AsyncPostfromfile to the NAS, at this point the PHP tempfile shows up meaning the transfer is done and stream-copy-to-stream is doing it’s thing.
The Roku can download a similar sized png from the same NAS way faster.
@EnTerr , at this point, this is pretty unimportant overall, it’s a nice trick for my own use. but I will try that when I can, I have to look up how to receive a file instead of a stream.
Hmmm, i guess i get to report first bug: roScreen.getPng() fails when screensaver is active
Discovered accidentally:
BrightScript Debugger> scr = createObject("roScreen"): ? scr.getWidth(), scr.getHeight()
1280 720
#' wait for SS to kick in
BrightScript Debugger> png = scr.getPng(0, 0, 1280, 720): ? png.count()
'Dot' Operator attempted with invalid BrightScript Component or interface reference. (runtime error &hec) in $LIVECOMPILE(58)
BrightScript Debugger> ? png
invalid
What’s the dealio with SS Blackenstein, i never really understood?
Also reporting a umm, feature:
With double-buffered roScreen, getPng() sources from the back buffer
“EnTerr” wrote:
@squirreltown, try to be more systematic about such things -
(a) measure time, sizes and
(b) use “divide & conquer” approach, e.g. include pre-saved PNG in your bundle and try uploading that instead of GetPng() one - my money are on it will take the same time. Then we can think what causes delay to your NAS upload
Sending a 1.5 mb .png file from pkg:/ takes one second.
Sending a 1.5 MB file should take the same amount of time, no matter what the file type is. I think the most important thing to know is the actual size in bytes of the result of GetPng, compared to the dimensions of the bitmap that went into it.
–Mark
