[wpe-2.38] Slower animation on navigation

[varumugam123]

Version : wpe-2.38 (0ac2e6f)

Problem : An issue was reported on Gensmak app on Comcast STBs (irrespective of SoC), where navigating the carousel is slower & not smooth. Observation with wpe-2.28 was better. I have stripped down the app and attached here for reference gensmak.tgz.txt

Other observations :

• During the navigation, the tiles aka element (with an image inside) get scaled. If I launch the same test app without images (i.e gensmak.html?loadWithoutImage=true), I see the animation (the scaling & the appearance of the yellow shadow box is a lot smooth)

Reproduction:

• Use the attached tar file to reproduce the issue
• Use Left & Right arrow keys for navigation
• Try both rapid navigation as well as slow one by one tile navigation to observe the visible delay in the animation

[magomez]

@varumugam123 can you check my comments in #1203 ? You may be suffering the same problem. The easy way to check it is by editing the file /etc/WPEFramework/plugins/WebKitBrowser.json in the device and removing the line that has "webprocesslimit":300 there, and then relaunching the browser.

Please tell me if that fixes the problem for you.

[varumugam123]

Hi @magomez, I did try removing the webprocesslimit. Below are the comparisons
Default behavior : Worse
w/o webprocesslimit : Slightly Better but still poor than wpe-2.28
with 2 Nicosia painting thread (the workaround we have in place as of now) : Lot Better than the above two (and comparable with wpe-2.28)

[magomez]

I've found that the async scrolling feature was adding some overhead to the rendering that may not be needed. Disabling it seems to make things better, but not sure whether it's good enough.
Can you give a try to the patch I'm attaching and tell me whether it makes things better?

disable-async-scrolling.patch.txt

[varumugam123]

Hi @magomez, The behavior remains same with the test app attached. There are some hiccups during navigation b/w tiles.

[modeveci]

@varumugam123 @emutavchi, If i am not wrong, you mentioned there is a workaround for this specific use-case and app (from app side). From our side @magomez can you give the latest update about our investigation?

[magomez]

I've checked that for the concrete use case there's an implementation change of flexbox that, probably to fix some bug, is repainting more pixels than on 2.28 when the animation is triggered. That's basically why the animation is able to render less frames and is slower, and also why it improves when increasing the number of rendering threads. There's not much I can do here as we can't go back to the previous implementation of flexbox.