Roku Developer Program

[RokuKC]

"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. 🙂

[squirreltown]

"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.

[RokuMarkn]

"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

[EnTerr]

"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

[EnTerr]

"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

[squirreltown]

"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.

[EnTerr]

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?

[EnTerr]

Also reporting a umm, feature:
With double-buffered roScreen, getPng() sources from the back buffer

[squirreltown]

"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.

[RokuMarkn]

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