Roku Developer Program

[TheEndless]

"squirreltown" wrote:

"TheEndless" wrote:

I think you missed the point. This splash screen is being displayed as the first screen of the app, so it doesn't need to be an roScreen. Display an roImageCanvas to avoid the flicker (except on the models noted above), then do a clunky fade to black on that splash screen to make a smooth transition into your roScreen based UI.

Well, I don't feel like i missed the point. Doing a dip to black is certainly an option, and if you like it thats fine. Personally it's one I've discarded. You are forced to fade in the roScreen if you don't want to see its underwear so I choose to get it over with early - for me its the best choice, but these are aesthetic work-arounds to deal with a bad technical situation.

Yes, but the OP is talking about showing a secondary splash screen while their making API calls in the background. There's no indication of needing an roScreen elsewhere in the channel, so the better option, in that case, would be to use an roImageCanvas instead of an roScreen to avoid a flicker between the built-in splash and the secondary splash. i.e., the point is to avoid a flicker between splash screens, not to avoid a flicker when instantiating an roScreen, which is a different issue.

[Komag]

"belltown" wrote:
I do use an roScreen for most of the UI, although I start off by displaying an roImageCanvas as a facade layer immediately, while the channel is doing its initialization, before that first roScreen is displayed...

Do you ever need to do run

facade.close()

?

When I tried it, it works great, and without calling 'facade.close() the roScreen just takes over, but is the roImageCanvas still running underneath, eating up some memory or whatever?

[belltown]

"Komag" wrote:

"belltown" wrote:
I do use an roScreen for most of the UI, although I start off by displaying an roImageCanvas as a facade layer immediately, while the channel is doing its initialization, before that first roScreen is displayed...

Do you ever need to do run

facade.close()

?

When I tried it, it works great, and without calling 'facade.close() the roScreen just takes over, but is the roImageCanvas still running underneath, eating up some memory or whatever?

I leave the facade underneath at all times because there are times when my roScreen component will call a built-in component, like an roSpringboardScreen. I invalidate the roScreen and its associated roMessagePort before calling Show () on the built-in component (and re-create them when the built-in component closes), in order to avoid problems with trying to have a custom 2D API component and a built-in component co-existing; also, if I don't invalidate the roScreen's port then I get events that were intended for the built-in component. If I don't have the roImageCanvas facade underneath when I invalidate the roScreen then the channel will exit as there are no longer any displayable components on the stack. The only time I call facade.Close () is right before the channel terminates.

I'm not sure what happens with memory though. However, after I've put the roScreen on display the first time, I will call Clear () and PurgeCachedImages () on the roImageCanvas and replace its layer with a solid gray-ish background color that matches the background color of the roScreen/roSpringboardScreen, etc. One reason to do this is so I don't get a momentary flash to my splash screen image when invalidating the roScreen before displaying the roSpringboardScreen. The other reason is because I'm not sure what happens with memory. It seemed like a good idea at the time to try to release the memory taken up by my 1280x720 splash screen image after it was no longer needed.

I'm sure there are other (better?) ways to do this - this is just what I found works for me.

[squirreltown]

"belltown" wrote:

I'm not sure what happens with memory though.

I'm pretty well convinced that the following is close to true.
The built in components have their own bucket of memory and its - A. Bigger then a given device's 2D API graphic memory( an arbitrary amount decided by the firmware designers) and B. Separate from the graphic memory. I say this because I've built a 2D version of roGridScreen and it can't handle the same # of thumbnails that the the built-in component does on the same low-memory-box like a 2XS - and theres no other explanation - same box, same thumbnails, and basically the same code approach (i.e. no other bitmaps sucking up memory). Also the 2D memory is "shared" with the video decoding memory - something the built-in components don't (i'm guessing) have to deal with.
The 2D API wasnt added so we could build actually nice looking UI's that weren't hampered by the built-in components restrictions - it was added because someone at Roku wanted to make the Roku a "game" platform. Of course as it turns out, the 2D API is actually better suited to UI's then games because of the all the hardware restrictions the Roku has ( CPU and RAM and openGL etc.) so it's still the red-headed stepchild, and no one has bothered to fix the glaring flaws mentioned in this thread, but hopefully they will, and realize that its the future of the Roku UI and actually (gasp) improve it.

[sonnykr]

Thank you Guys for all your comments. I tried placing the image on imageCanvas, but still, there was a black flash when roScreen is created.

Later on, I fixed this issue by avoiding the default splash screen by putting a black splash screen and splash_min_time=0. So when the app launches, the custom splash screen (roScreen) is loaded directly. There is a moment of black screen initially, but its acceptable. Seems like YouTube took the same approach.

[TheEndless]

"sonnykr" wrote:
Thank you Guys for all your comments. I tried placing the image on imageCanvas, but still, there was a black flash when roScreen is created.

Later on, I fixed this issue by avoiding the default splash screen by putting a black splash screen and splash_min_time=0. So when the app launches, the custom splash screen (roScreen) is loaded directly. There is a moment of black screen initially, but its acceptable. Seems like YouTube took the same approach.

Just as a heads up, if you're planning on publishing the channel publicly, a black splash screen probably won't pass QA.

[waji]

In my app, I use a secondary splash screen, which is launched right after the roku default splash screen. The secondary splash screen does a bunch of API calls before launching the app.

<b><a href="https://rag-code.net" title="먹튀커뮤니티">Targeted Keyword</a></b>