Roku Developer Program

[MSGreg]

In Version 3.1, I'm working with roScreen and DrawScaledObject and seeing some bizarre results that appear to be memory corruption with occasional reboots. I've also gotten the device into a mode where the screen is split halfway between each of the buffers when double buffering. This condition remains when exiting to the main channel, requiring a reboot to fix.

The conditions appear to be when the destination and source are the roScreen or Bitmap object and only when using DrawScaledObject, even when scale is 1.0. These effects do not occur when using DrawObject.

To ameliorate some of these issues, I've created an roRegion that is 65 percent the size of the screen and use that as the destination. This seems to generally work, but I still see some artifacts and (less) occasional rebooting.

With scales slightly less than 1, I see artifacts that look like the horizontal hold on an old TV is broken. Depending on the size of the roRegion, these lines will disappear at a scale of about 0.5, or they may continue at all scales below 1.0.

Also, I know I can crash the box (reboot) with a scale of about 500.

Again, this happens only in 3.1, not 4.8.

This is not the same as this DrawScaledObject bug.

I know this isn't a full reproducible report, but I'm looking for anyone that might have run into this problem and, if possible, general suggestions on how to go about avoiding these problems.

[MSGreg]

Further, currently, when I scale between 1 and 0.74, I see the "horizontal hold" corruption, and below 0.74 it crashes the system every time.

The behavior seems very dependent on the exact sizes used. I am currently using 1280x720 screen/bitmap and a destination region on the screen of 65% of the full screen size as mentioned above.

[TheEndless]

I've never seen what you're describing, but then I don't think I've ever scaled a full screen bitmap before. I have, as noted in the thread you linked to, seen quite a few annoyances with scaling on 3.1 quality-wise, and have found that I get significantly better results if I use regions for both the source and target, even at 100%. So what I usually do is just wrap the bitmaps/screen in a region before doing the DrawScaledObject:

targetRegion = CreateObject("roRegion", targetBitmap, 0, 0, targetBitmap.GetWidth(), targetBitmap.GetHeight())
sourceRegion = CreateObject("roRegion", sourceBitmap, 0, 0, sourceBitmap.GetWidth(), sourceBitmap.GetHeight())

sourceRegion.SetScaleMode(1)
targetRegion.DrawScaledObject(x, y, .75, .75, sourceRegion)

[MSGreg]

I'm still seeing this behavior when using roRegion for both source and destination. Not sure what to try next besides smaller areas...

[MSGreg]

Wrapping the source in an roRegion AND with SetScaleMode(1) on the source seems to prevent the visual portion of the corruption bug listed in this thread. I am still seeing reboots when the scale is very small and very large (somewhere below 0.003 and over 7000). Not a huge problem because that is either smaller than a pixel (or a few pixels) for the small scale, and a single pixel blown up on the large scale. I can test for values outside the range and simply not draw when they occur (and live with the "wrong color" on the large scale). Though there is a huge difference in speed drawn vs. not drawn, I may be able to adjust for that with an inserted sleep.

A big drawback overall is that the scaling operation with SetScaleMode(1) is very slow on old devices, perhaps one second on full screen source/destination. It gets faster as the scale parameter gets closer to 0.

[RokuJoel]

We have a bug report on this from last year, it was decided not to fix this issue on 3.1 as it would be a major effort to upgrade this subsystem. Doesn't mean it might not eventually be fixed, but the likelihood is low.

- Joel

[MSGreg]

Thanks, TheEndless and Joel. I'm working around it in my application. The result is not ideal, but it is functional.