Roku Developer Program

[renojim]

Is there such a thing as the maximum update rate of an roImageCanvas? I was working on a simple animation that didn't look too bad on build 677, but I just got build 687 and it looks like the update rate has gone down drastically making the animation look very choppy. Every time there's an update to the firmware my cute little experiments stop working. 😞

-JT

[RokuKevin]

If you are able to download all your art and use it locally, you can probably quit using SetRequireAllImagesToDraw() which took a big (but necessary) performance hit between those builds.

--Kevin

[renojim]

"RokuKevin" wrote:
If you are able to download all your art and use it locally, you can probably quit using SetRequireAllImagesToDraw() which to a big (but necessary) performance hit between those builds.

--Kevin

Ah! Thanks, I'll give it a try. I know this has been mentioned many times in the general forum, but it really would be nice to know what changes were made between firmware releases.

-JT

[renojim]

Well I tried SetRequireAllImagesToDraw(false), but I can't see any difference whatsoever. It seems like it's only updating the screen maybe every 10th call to SetLayer().

-JT

[RokuKevin]

Did you pre-download your art (via roUrlTransfer...) and then reference "file://tmp:/myimage.jpg" type urls in the roImageCanvas?

--Kevin

[renojim]

It is a very small gif (837 bytes) that is part of the package, so I'm referencing via "pkg/images/file.gif". I'm just trying to get it to move across the screen and it worked pretty well before build 687. I call SetLayer() with a new TargetRect after doing a "wait(30,port)" in a continuous loop. I've tried other values for the timeout as well. It appears that the screen is only redrawn maybe every 10 calls to SetLayer(). It's one of three layers, not counting the background layer. One layer never changes after the first time it's drawn and another only changes once a minute or so. It's the third layer that I'm trying to update as often as possible.

-JT

[RokuKevin]

Jim,

If you can send me a private message that includes some test code to recreate this issue, I'll see that we take a deeper look at the performance problems you're seeing.

--Kevin

[kbenson]

I've also seen roImageCanvas updates queued and applied at a later time. It seems somewhat related to the fact that the show() method doesn't block until the screen updates, but returns after a rather standard amount of time, somewhat independent of what's already displayed on the canvas. The actual display doesn't update until afterward, and the time before that happens is highly dependent on what if already on the canvas.

If you come up with any techniques to speed this up, or if any change is planned to the firmware, it would be great to get an update here.