Teletext Subtitle Rendering issue

[modeveci]

Steps:
Boot the STB with the Irdeto reference RDK-VA, and enable the subtitle in settings.
Tune in to the service with the DVB subtitle.

The following are the observation:
While displaying the teletext subtitle on the Video player screen.
Instead of actual teletext, white blocks like garbage texts gets displayed randomly. The following logs are observed when the issue arises:

“ Apr 04 06:50:08.781255 WPEFramework[6275]: [ResidentApp]:lightning.min.js:7,237602 [Lightning] GC! Frame 61323 Freed 0.17MP from GPU memory. Remaining: 1.14MP Apr 04 06:50:08.781255 WPEFramework[6275]: [ResidentApp]:lightning.min.js:7,237874 [Lightning] Textures: 1.14MP, Render Textures: 0.00MP, Renderer caches: 0.00MP”

The Issue kicks in after running the teletext Subtitles for a while. Initially it will display the text properly. Once the issue kicks in, it’s not recoverable without a reboot.
The screen PFA display when the issue happened.
The Issue happens when we display Teletext Subtitle only. If we use DVB Subtitle (Pure
Image) There is no issue.
What we also discovered was that, if the dimension of the teletext is made smaller the issue did not surface for a long time.

Few Other observations.:
Following was the advise from RDKM
"
Hi Keisham,
If you use one of the latest Lightning versions, you should be able to use this setting to fix the issue:
forceTxCanvasSource: true
It’s related with the uploading of the source towards the GPU (it forces it to be uploaded as 2dcanvas instead of bitmap data).
Best regards,

--> Outcome : The issue was note resolved , also Teletext subtitle was not displayed.

We have made the changes on our end and made sure we are loading Lightning 2.7. We found a reason as to when the issue happens. The issue only kicks in when the Container for drawing the subtitle is large, Example 1500px container size will give this issue, but 800px its OK.

[modeveci]

Same problem has been reported in another use-case, and same conclusion:

We've found this is size related. If the canvas size is <=65700 its fine, anything over that and we don't see text.

[magomez]

From the description and the screenshot I think that the problem here is the canvas created is big enough to become accelerated, which means that cairo is using opengl to render to it, and there seems to be a bug in cairo gl rendering text in some situations, and that generates exactly the output that is gotten.

I saw this before, and there's a size requirement into the code to avoid accelerating the canvases as much as possible due to this. The current threshold is that the canvas must be bigger than 1/4 of the display area. I guess that at some point the created canvas is bigger and it becomes accelerated, and hence the bug. And that's why you're finding that the bug is dependant on the size of the subtitle.

The problem to fix this is that there's no easy way to differentiate when the canvas should be accelerated and when it shouldn't. I'm using the size to try to make big canvases accelerated for potential games, and smaller ones that can be used for text non accelerated, but it's not optimal. I'm going to push a patch that changes the threshold from 1/4 of the display area to 1/2 of the display area and this will probably get fixed, unless at some point the subtitles are long enough to fill 1/2 of the display.

[magomez]

I've just pushed 0df71ef to the wpe-2.38 branch. Could you test whether the problem is fixed, and close this if so? Thanks!

[wouterlucas]

Is there anything we can do on the Lightning end to ensure a canvas doesn't accelerated? Like ensure its a size X based on viewport and then just sample it to a texture and increase the size from there? Risking blurry scaled fonts but at least that's better then the accelerated version.

Alternatively we could throw an error if someone tries to create a too large size?

[magomez]

Is there anything we can do on the Lightning end to ensure a canvas doesn't accelerated? Like ensure its a size X based on viewport and then just sample it to a texture and increase the size from there? Risking blurry scaled fonts but at least that's better then the accelerated version.

With the current patch, any canvas whose size is equal or bigger than 1/2 of the display size will be accelerated. That's what we don't want. As you say, if you detect that situation and avoid it by using a smaller canvas and then scaling it up later, that would avoid the problem entirely (well, assuming that the problem is what I explained). That would be awesome. I don't expect subtitles to fill half of the display, but who knows.

Alternatively we could throw an error if someone tries to create a too large size?

I wouldn't throw an error, cause it's a valid use case. The fact that it doesn't work is not an app problem, but a cairo limitation.

[wouterlucas]

Is this an issue that will automatically go away with shifting away from Ciaro? Or is that no longer happening with Skia?

[magomez]

Is this an issue that will automatically go away with shifting away from Ciaro? Or is that no longer happening with Skia?

It shouldn't happen with skia.

[erikhaandrikman]

Is there a way for us to set this to avoid canvas being accelerated?

WPEWebKit/Source/WebCore/html/HTMLCanvasElement.cpp

Line 900 in 0df71ef

if (!settings.canvasUsesAcceleratedDrawing())

[magomez]

Is there a way for us to set this to avoid canvas being accelerated?

WPEWebKit/Source/WebCore/html/HTMLCanvasElement.cpp

Line 900 in 0df71ef

if (!settings.canvasUsesAcceleratedDrawing())

You shouldn't change that, as that would completely disable the accelerated canvas, which is something we don't want because some canvas games will become unusable.
From the lightning side, the check for the size mentioned should be enough, if you want to do something. I don't think this is going to be a problem anymore with the new size, and it should not be a problem in future releases with skia, so even not doing anything on your side should be fine.

[modeveci]

@wouterlucas Based on these feedback, will you follow-up the ticket and the fetch issue reported a while ago? Or is there anything we need to investigate further? What do you think?

FYI @woutermeek

[magomez]

We should first wait for verification that my patch fixes the problem, just in case.

[wouterlucas]

@wouterlucas Based on these feedback, will you follow-up the ticket and the fetch issue reported a while ago? Or is there anything we need to investigate further? What do you think?

FYI @woutermeek

I will, already gave RDK a preliminary update with the findings here (there are 2 accounts where this is happening) and then will send them after @woutermeek for a delivery once @magomez gives a green 🚥

[wouterlucas]

Really happy you found this - this particular bug has been haunting us for years now 😃

[modeveci]

My mistake I labelled as wpe-2.38, but it has been reported for RDK5 (which is more likely 2.28). Maybe first good to use as a patch on affected apps/use-cases.

Before making any changes on 2.38, it needs to be extensively tested. @magomez can we revert this patch?

[modeveci]

@emutavchi feel free to share your feedback on this issue. Thank you very much!

[magomez]

Before making any changes on 2.38, it needs to be extensively tested. @magomez can we revert this patch?

Sure, reverted.