Roku Developer Program

[retrotom]

Some quick questions before attempting to implement something:

Is there limit to the number of layers that can be used with roImageCanvas? If so, what is it?

Does performance scale with the number of layers used? I'm aware that this might depend on content (images/text used) -- so is it more efficient from a rendering perspective to group content in to a single layer or break it into many layers? Let's make the assumption that the image/text layers will need to be updated quickly based on user input.

Thanks,
RT

[TheEndless]

I'm guessing you're asking for an official Roku response, but here's my 2 cents...

I have no idea if there is a limit, but I've had easily close to 100 layers or more without issue. As for performance, I've only noticed an appreciable difference based on content, rather than quantity. The biggest drag being large images, scaled images, and transparent overlays. Using "Source" instead of the default of "Source_Over" wherever possible helps somewhat. Slicing your larger images (i.e. over half the screen height or width) into smaller chunks also helps a lot (this can be done using SourceRect rather than literally slicing your image into multiple files). Setting SetRequireAllImagesToDraw to false helps if you have a lot of images. And finally, I've also found that keeping your static layers separate from your dynamic layers is a good idea, so you're not redrawing content unnecessarily.

[retrotom]

Nope, that reply was good enough for me. I'd thought of your last suggestion (separating dynamic/static content) and was concerned with the performance of the dynamic layers. For instance, I would have a "dynamic" layer for each entry in a filebrowser or playlist and static layers would be used for overall "theming". My initial concern was with number of layers -- but I don't think I'll go over 100 -- and if I do it won't be by much. And my secondary concern was performance -- how fast could they be updated. Because each layer has its own z-index, I didn't know if there was some kind of performance penalty or benefit for occlusion. It sounds like it'll work (looked OK based on documentation before I posed the questions), I just wanted to run it by someone before I started hacking away at something.

Thanks,
RT

[kbenson]

"retrotom" wrote:
Some quick questions before attempting to implement something:

Is there limit to the number of layers that can be used with roImageCanvas? If so, what is it?

From our testing the layer number seemed to be an arbitrary number used for z-index calculation. We testing with layers into the millions (not with images on every layer, obviously). It appears any limit to layers is imposed by the ram used, as each layer uses a different amount of memory based on the image added (from what we can tell).

Does performance scale with the number of layers used? I'm aware that this might depend on content (images/text used) -- so is it more efficient from a rendering perspective to group content in to a single layer or break it into many layers? Let's make the assumption that the image/text layers will need to be updated quickly based on user input.

Definitely. The more images in a canvas, the slower it seems to update. I believe it updates slower with more overlapping images as well (but that may depend on whether source or source_over was used). With complex enough compilations of images, there are techniques to mitigate this. Look at one of the threads about ImageCanvas performance (or just about any thread with ImageCanvas in the title). TheEndless, renojim, myself and others have put quite a bit of work into tweaking it to be performant, and it should be mostly documented in those threads.

[retrotom]

Thanks for the additional info. I'll be sure to search the forums for your prior research :D.