Texture rendering issue on Ziggo devices

[evgeniy-legkun]

Hello everyone. The new workaround tended to fix artifacts on some browsers (e.g. Tizen) implemented in this PR - https://github.com/rdkcentral/Lightning/pull/345/files does not work correctly on Ziggo devices (EOS, Selene). The behavior is random, most of the time we do not see the text (TextTexture texture) at all, or weird symbols are drawn.

See the screenshot

The issue comes from this line of the code that was released with version 2.5.1.

We had to freeze the Lightning core with the 2.5.0 version on our project and are not able to use newer versions in production because of this. Probably this is some browser-specific issue since we reproduced it only for the devices (e.g. Ziggo) that use Gecko-based browser (Firefox in our case) underhood. Actually, I can not say what is the issue, but it is defiantly related to the getImageData() function calling. The 2d context attribute "willReadFrequently" (see https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/getContext) setting with neither "true" nor "false" did not help.

Please, investigate this issue or consider rolling back the PR mentioned above if it is possible. If need to check something on the actual device (I have Ziggo EOS) I can do it if have free time.

Regards

[g-zachar]

Hi @evgeniy-legkun,

I don't have access to Ziggo EOS. If you can find a way to distinguish your platform in JS runtime I can apply the revert for it specifically:

https://github.com/rdkcentral/Lightning/blob/669095186eb68f3d60599b498b1a0f192fdd462b/src/tree/Utils.mjs#L193-L197

Best regards

[evgeniy-legkun]

Hi, @g-zachar I was looking for a way to distinguish the Ziggo platform assuming to parse a UserAgent, this does not look like a robust solution but I could not find the better one. Looks like the "lightning/sdk" Profile plugin does not have similar logic as well.

Take a look at the UserAgents examples (obtained from the devices): 1) Ziggo Selene (king of old device, has the same issue): Mozilla/5.0 (Linux armv7l) AppleWebKit/602.1.28+ (KHTML, like Gecko) Version/9.1 Safari/601.5.17, VirginMedia_STB_00.3041.0747.A4/SMTG7401-mon-dbg-00.02-000-fa-AL-20220107210001-un000 (Samsung_liberty,SMT-G7400,Wired) HZN/4.40 (MN=SMT-G7400;PC=HZNSTB;FV=SMTG7401-mon-dbg-00.02-000-fa-AL-20220107210001-un000;)

2) Ziggo EOS: Mozilla/5.0 (Linux armv7l) AppleWebKit/602.1.28+ (KHTML, like Gecko) Version/9.1 Safari/601.5.17 HZN/4.34 (MN=DCX960;PC=EOSSTB;FV=DCX960__-mon-dbg-00.02-120-fq-AL-20210806210000-un000;)

Proposed condition to exclude both mentioned above devices is (they are all Ziggo, only different revisions): Utils.isZiggo = Utils.isWeb && (navigator.userAgent.indexOf("EOSSTB") !== -1 || navigator.userAgent.indexOf("HZNSTB") !== -1);

Does it look like a plan?

Best regards

[g-zachar]

@evgeniy-legkun

Looks good enough, I'll prepare a PR you'll be able to test.

Best regards

[g-zachar]

@evgeniy-legkun

Let me know if #364 works for you.

Best regards

[evgeniy-legkun]

@g-zachar Yes, it works great! Checked on Ziggo EOS. Waiting for the release, hope it does not take lots of time, this issue is kind of blocking. Thank you!

Best regards

[yvbeek]

@erikhaandrikman Reopening this issue. We have an app for the Sky platform and we've noticed rendering issues, like the one described here, on the Titan boxes. Would it perhaps be possible to change the implementation so that it only applies the ctx.getImageData(0, 0, source.width, source.height)) workaround for specific user agents? That might be a safer approach, so that it works like it did in the older versions.

[g-zachar]

@yvbeek Reverting the default behavior now would result in regression on a different set of platforms (we don't have the full list of affected platforms nor a way to identify them at this moment). In my opinion, the best approach at the moment is to stay with the current default, keep gathering affected platforms and add exceptions for them and perhaps refactor this solution in the future.

[yvbeek]

@g-zachar Ah yes, I can see how that is difficult. On the other hand there could be a lot of platforms that haven't upgraded to the latest versions yet and they might encounter the same rendering issues. Perhaps it would be good to highlight this issue in the changelog?

For now a workaround for the Sky Titan box might be to add an exception based on the user-agent:

Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.9.7 Chrome/56.0.2924.122 Safari/537.36 Sky_STB_BCM7278_2019/1.0.0 (Sky, ES340UK, )

Think we might have to test for the Sky, ES340 part. The ES340 indicates the Titan model, as this issue does not seem to affect all Sky boxes.

[yvbeek]

@g-zachar Could you please add the exception for us? We could test for the Sky, ES340 part

[g-zachar]

@yvbeek let me know if the fix works for you.

Best regards

[erikhaandrikman]

@yvbeek any updates on this?

[Serhii-the-Dev]

The #364 fixed the issue only partially on Ziggo devices, here is another PR covering a missing device: https://github.com/rdkcentral/Lightning/pull/421

[jacek-skiba-red]

I'm maintaining WPE browser for Ziggo / Telenet / VirginMedia (LibertyGlobal family) and from my point of view setting condition based on UserAgent is very weak:

• for Ziggo we are using EOS and EOS2 STB and here UA matching is OK
• for other countries (eg. VirginMedia) we use using different boxes, with different UA
• new types of boxes are comming, also with different UA

We will investigate this issue on CPE side. I have assumption that this may be fixed by Cairo library upgrade to version 1.16. Similar problem related to putImageData was discussed here: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/935

[michielvandergeest]

Hi @jacek-skiba-red, we totally agree that matching based on user agent isn't the way to go. We consider this part of the codebase an historical artifact. That's why we introduced the forceTxCanvasSource option so this can be triggered via a configuration setting.

We are all good with removing the UA matching all together. Would that be okay for you, or do you think that will cause issues on existing LGi deployments?

[jacek-skiba-red]

@michielvandergeest: logic based on forceTxCanvasSource options is OK for us. To not cause any regression on LGI boxes, we need to have this option backported to each release, starting from release 2.5.1 (https://github.com/rdkcentral/Lightning/releases/tag/2.5.1). is it feasible?