There's a bug here somplace
I don't know what to make of this other than there appears to be a bug in the Roku 2 firmware. It's pretty hard to explain, so I'm just going to give the code to reproduce it. Function BuildTex...
Forum Discussion
"kbenson" wrote:"renojim" wrote:
There's still the issue of why DrawText is so much slower on a Roku 2.
We've found the Roku2 to be slower in general. Then again, we basically re-made everything roCompositor does in pure BrightScript. With a highly optimized processing loop (lots of GOTOs to skip loops and sub-loops where we can detect it) and all direct calls to DrawRect on the base roScreen, we're achieving 60 fps on Roku1, but the Roku2 can't keep up.
We're just not moving into porting stuff to using roCompositor and sprites to test the difference, hopefully having collision detection handled by the component is much faster than doing it ourselves. It's possible that the Roku2 is slower in select areas, and we happen to be using them heavily.
If roCompositor supported scaling, I'd try going that route myself, but it's just too limited in that respect. I'm actually having the opposite problem, though. I can get 60fps on Roku 2, but get about 3 fps with the same code on Roku 1. Granted, I'm drawing/compositing custom bitmaps on demand (due to serious memory limitations when it comes to caching bitmaps), so it's probably a different part of the processor being used in my scenario.
