Roku Developer Program

[speechles]

On firmware 11.5 and every single one prior when using a poster node you could use LoadWidth and LoadHeight to control how much was consumed in texture space. Since texture space is where you run into problems.

The documents state that when loadwidth and loadheight are used, and width and height are left at zero it will inherit the width/height from the loadwidth/loadheight. Which works on all firmware prior to 12.0.

Now with firmware 12.0 it always uses the height/width of the bitmap itself to render onto the screen rather than inherit that height/width from the loadwidth/loadheight used.

This change in behavior should be noted on the documentation for the poster node. As right now there is conflicting information there.

It says on Width/Height if left as zero will inherit as the bitmap size. Okay. All good.

But then on LoadWidth/LoadHeight it says if width/height are zero but loadwidth/loadheight are set it will inherit those values into width/height. Here is where I can say the documentation is lacking and confusing.

To me this is a bug in firmware 12.

Can anyone confirm to me that has access to firmware 12 that I am not crazy. Thanks. 🙂

[renojim]

Do you have loadDisplayMode set?  I notice if I don't set that the loadWidth and loadHeight don't affect the displayed poster.  It defaults to "noScale".

[speechles]

Yes. loadDisplayMode="scaleToFit"

Which should respect the loadwidth/loadheight (texture cache savings) and inherit those into width/height (fit to screen space requested the image using that texture) when those are left at zero with loadDisplayMode="scaleToFit".

But instead what happens is the bitmap width/height is inherited instead which should only happen when loadwidth/loadheight is left at zero. If you use loadDisplayMode="limitSize" it will not scale to fit or fill or zoom that texture to the image size. It will just remain the size of the loadwidth/loadheight. You must use ScaleToFit or ScaleToFill or even ScaleToZoom to get there. These used to respect the same behavior as "limitSize" and give the ability to scale on top while passing loadwidth/loadheight into width/height. So something changed here in a not good way.

The weird part is 11.5 and prior have all worked perfectly fine with this code for years. It is only now with firmware 12.0 that this is a noticeable (pun intended) problem.. lol.

I was just hoping to get the documentation in that regard for the poster component cleared up. Something in firmware 12.0 changed in regards to this. Needs clarifying. That is all. 🙂

Side-note: Those mutliple captcha of click the motorcycle/streetlight/bus/crosswalk stuff is demeaning to us humans... and annoying.

[renojim]

I don't think I'm seeing what you're seeing.  I assume you're using r2d2_bitmaps to check the texture memory?   I tried with a 3024x3024 6MB bitmap with loadWidth set to 1000 and loadHeight set to 750 and I get this:

0x04799743   666    500   3  1376256        0    1    0 <dev_332a_52>http://192.168.0.118/test.jpg?3751

 This is on a box that doesn't support FHD, hence the 666x500.

I may not understand exactly what you're speaking about and will admit you know a lot more than me about graphics and the texture cache. 😀

I did receive an email recently indirectly about one of my channels and 12.0.  There was definitely a change in the image handling and I had to add loadSync=true for my case, but I don't think that applies here and I tried it both ways without any difference.  Maybe @RokuBen can give some more details about what changed.

I'm using a 3910 on 12.0.0 build 4123 in case that matters.

I couldn't agree more about the freaking captcha!

[speechles]

You used 1000 x 750 and got 666 x 500 is correct for 720P. 720P = multiply by 0.666666(repeat forever) or 2/3rds.

What I mean is this:

loadwidth="1000" loadheight="500" width="1000" height="500"'

The above would work around the problem. But brevity is always better and it has always worked up until this point. We were using it exactly as below.

loadwidth="1000" loadheight="500" width="0" height="0" loadDisplayMode="ScaleToFit"

Now where it has width="0" and height="0" is just there to show. Omit those as the default for those is the same. Just leave loadwidth and loadheight and the loaddisplaymode.

With your 3084x3084 image on 11.5 firmware it will constain on 720P to 666x500 in texture memory which is correct. Then it will display into the width/height inherited from the loadwidth/loadheight and display at 666x500. But on 12.0 firmware with 720P it will constrain incorrectly It will cache to texture memory correctly at 666x500 but the display area will be inherited from the bitmap size (instead of the loadwidth/loadheight size) and become 3084x3084 (which will render as 2056x2056 on 720P).

This is the part where something has changed.

Now you can say just use loadDisplayMode="limitSize" and it will do what you want if the image is oversized. Okay. Granted. But lets say you do not know if the image is smaller or larger than your intended area to display. This makes limitSize only work when the bitmap image size is larger than the loadwidth/loadheight you intend. When it is smaller and you use limitSize your image will not scale up. Hence why the fact ScaleTo(Fit/Fill/Zoom) working with loadwidth/loadheight and passing into width/height was very magic. It worked with both oversized and undersized images. Now that magic is broken.

Now you can also say, just know from the bitmapWidth and bitmapHeight when you tie either of those fields to an observer along with the image node and act accordingly. Okay, but having this on a grid as the item component is too much work for this to be acceptable. It is slow. You notice the lag. So doing too much with observers and what not inside the grid item component isn't something you should do.

Especially with images you should not do too much, as you can attest. I do not want to use the loadSync="true" since it will cause the items (overlays inside the PKG not web sourced) on these "cards" to get built out of order and appear first. I like the card to just pop into place when it is entirely ready. Not have bits and pieces appear as they load. It detracts from the experience. We use loadSync="false" as often as possible because of this.

This is why the magic needs to come back.

[renojim]

---

@speechles wrote:

With your 3084x3084 image on 11.5 firmware it will constain on 720P to 666x500 in texture memory which is correct. Then it will display into the width/height inherited from the loadwidth/loadheight and display at 666x500. But on 12.0 firmware with 720P it will constrain incorrectly It will cache to texture memory correctly at 666x500 but the display area will be inherited from the bitmap size (instead of the loadwidth/loadheight size) and become 3084x3084 (which will render as 2056x2056 on 720P).

I'm not seeing that.  I've tried with the 3084x3084 JPEG and a 240x180 JPEG and they both render and cache at 666x500 on two different devices (that don't support FHD UIs).  I don't have a FHD device on 12.0.

Do you have some code you'd like me to try?  Mine is just this:

    bs = m.blank_screen

    poster = bs.createChild("Poster")
    poster.loadheight = 3*250
    poster.loadwidth = 4*250
    poster.loadDisplayMode = "scaletofill"
    poster.translation = [100,100]
    poster.uri = "http://192.168.0.118/x.jpg?" + rnd(9999).toStr()
    REM poster.loadSync = true
    poster.visible = true
    bs.visible = true

[RokuBen]

Yes, a reproduction is the best way to get this addressed, ideally a ZIP file that just shows the problem.  In Roku OS 12.0, the graphics system has been reworked extensively to allow for better use of system resources, but it does mean that some image processing gets delayed until the image is actually used to draw on screen unless you set loadSync=true for a Poster.