You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
@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.
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)
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?
@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?
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.
Activity
[-][wpe-2.38] Slower animation on navigating[/-][+][wpe-2.38] Slower animation on navigation[/+]magomez commentedon Feb 2, 2024
@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 commentedon Feb 6, 2024
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 commentedon Feb 27, 2024
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 commentedon Mar 20, 2024
Hi @magomez, The behavior remains same with the test app attached. There are some hiccups during navigation b/w tiles.
modeveci commentedon Apr 10, 2024
@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 commentedon Apr 10, 2024
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.