Roku Developer Program

[coredump]

I am drawing a "grid" of movie posters and wondered what the best way to simulate scrolling would be. Should I simply detect the bottom and then shift all the images up or is there a better way to approach this ?

[NewManLiving]

While it is certainly possible to do this, scrolling in ImageCanvas is real slow and uneven. If you are really into custom design you will eventually find the ImageCanvas useless for the complexity that you are considering, as most of us who have taken this route eventually found out. Do yourself a favor and learn the 2D API

[coredump]

Is that also why the screen waits for all the images to load before displaying instead of showing them one at a time as they load ? Also, is there no way to use double buffering without the 2D API ?

[NewManLiving]

Yes that is possible, but you will not get the same results. Double buffering is guaranteed not to tear the visible image :roll: For a real smooth scroll like the built in grid double buffering is the most optimal. If you are using the 2D API on anything less than the 3 box, you should use roBitmap.Finish() as well as the undocumented
roRegion.Finish() ( if you are using regions ) to avoid an annoying flickering that occurs from time to time. I'm not sure if this flickering is related to other threads that discuss this same problem. But for me, these two methods took care of all the flickering so far. Writing a decent grid in the 2D is a real challenge, probably one of the most complex, especially if you are using the textureManager to populate the grid. However it is very doable, I had this same goal and recently completed it.
In my own experience I find that using compositor, regions and sprites offers the best results. Anything that you can do outside of BrightScript is always smoother and faster, especially on the lower-end boxes. For example, region offsetting handles your scrolling internally as opposed to you offsetting the x,y coordinates of a nested array of bitmaps as the user scrolls. The compositor DrawAll handles all drawing of sprites in a complex interface internally. There is additional coding and overhead involved but there are ways around these things as well ( frameworks, offloading ).

[TheEndless]

"coredump" wrote:
Is that also why the screen waits for all the images to load before displaying instead of showing them one at a time as they load ?

Try calling roImageCanvas.SetRequireAllImagesToDraw(False).

If you're not requiring animated scrolling, you may be fine with the roImageCanvas, but for anything that requires a decent framerate, the 2D API is the better option.