How can your app know when the screen is done drawing?

It appears by removing the line to require all images to draw fixes the problem. How strange. 3.0 beta firmware

ok, still seeing this 'issue' . The roImageCanvas is set to pull 6 or 7 graphics from the server to create the screen to display. Sometimes on entering the channel it immediately shows a black background which is the default Image Canvas and one or two of the loaded graphics, and 30 seconds later or so it displays the rest of the images on the screen. Other times it shows the black screen immediately and then about 30 seconds later it displays the entire screen. And sometimes it displays the entire screen instantly when the channel app starts up. Similar behavior occurs when closing a grid screen created on top of the image canvas screen. I'm open to any suggestions - would any of these ideas help?

Using roUrlTransfer to download all images used to tmp first, then using rofilesystem to verify the byte sizes of the downloaded files, and then drawing the images to the canvas?
Forcing the garbage collector to run when the gridscreen is closed and creating a facade screen to prevent the prior canvas image from displaying until the garbage collection is finished?

Because what I also see is - when the gridscreen is closed, you can see the canvas fully drawn, which is great, and pressing buttons on the remote play sound like they should be immediately when the button is pressed, but the graphics aren't being updated until it's entirely done closing the gridscreen, so some delay is there too.

Does a question require a bump to get any guesses? Even with the images downloaded to tmp first, the roku appears to be quite busy as a larger gridscreen closes, so unless I add a 5 second delay to comnpensate (which is quite long) the delay would need to be variable duration.

We actually discussed this in depth awhile back.. I don't think we ever found a definitive method, but let me see if I can find the thread...

EDIT: Yeah, we discussed it here (not as "in depth" as I thought).. looks like the same general results as you're seeing: viewtopic.php?f=34&t=31062&p=190596

Thas for the link - no solution, so I'll mark it off the list of bugs to look at.

Getting roImageCanvas working the way you want is all about timing, putting sleep() statements in various places and experimenting till something works. Also, imagecanvas starts off slow, and then speeds up if you keep drawing to it. You can actually have multiple objects moving around the screen and get some almost "sprite" like effects and but have no luck getting a single object to do what you want. In short its is a mystery and you can find things that work by experimenting. In the time it takes to draw one object, hundreds or thousands of brightscript statements can have executed, so you might as well draw a pile of objects. As some of the threads have discussed, you can draw faster if you section an image into little chunks and draw each chunk to a separate layer.

- Joel