Bug 101162

Summary: Weston window frames for Xwayland views cause performance problems
Product: Wayland Reporter: Ilia Bozhinov <iliyabo>
Component: westonAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Ilia Bozhinov 2017-05-24 06:25:02 UTC
To reproduce the issue(at least on my machine this is the behavior, I'm using weston 2.0.0):
Open chromium/chrome, load a youtube video, leave the pointer above it, after a few seconds it will "hide". At this moment the FPS of the video drops considerably(or probably this is the compositor's FPS) and the video lags. When I move the cursor again so it becomes visible the problem goes away until it gets hidden again. This doesn't happen with fullscreen video, maybe the black surfaces that weston uses or something similar is the reason behind this, as on my WM it happens with fullscreen windows and I don't use black surfaces.
Comment 1 Pekka Paalanen 2017-06-05 08:25:00 UTC
Is this going through Xwayland?

One thing that comes to mind from hiding a cursor is that some other surface could be promoted to the cursor plane given size and format restrictions. The cursor plane path is pretty copy-happy.

Do you see any process hogging the CPU more than usual when the lagging happens?
Comment 2 Ilia Bozhinov 2017-06-05 14:29:58 UTC
1) Yes, this is through Xwayland

2) No, there are no processes that use more than 1% CPU(and they have the same cpu % as before playing the video), it's just chrome that uses CPU.
Comment 3 Ilia Bozhinov 2017-06-09 17:10:01 UTC
Well, after a bit of poking around it seems that the problem isn't related to the pointer being hidden(I managed to reproduce it while the pointer is still visible, but the video lags). However I managed to record the framerate, and there is a noticeable drop - from 60fps when it plays smoothly to 30fps when it lags.(Framerate recording isn't the most reliable, but still it shouldn't vary so much)
Comment 4 Ilia Bozhinov 2017-06-16 12:46:09 UTC
After a little bit more experimenting and debugging with valgrind, I found out that the cause of the lag is the window frames which Weston is drawing. If I uncomment all the relevant lines in xwayland/window-manager.c, then performance is better(for ex. glxgears runs at 9000fps instead of 7600fps with vblank_mode=0) and there is no more lag in chrome.
Comment 5 Pekka Paalanen 2017-06-19 07:51:36 UTC
Hi,

The difference from 9000 to 7600 fps is the change from 111 us to 132 us, while screen refreshes are in the order of 10000 to 20000 us, depending on refresh rate. IMO it is proof that glxgears does not suffer from the issue described, because 21 us cost for decorations is pretty much nothing.

Attaching decorations to the Chrome window causes a significant slowdown, but is it only when playing video in Chrome?

If the slowdown happened regardless of web page content, I might suspect a pixel format difference between the decorations and Chrome content.
Comment 6 Ilia Bozhinov 2017-06-19 07:58:45 UTC
Performance in chrome is something I find pretty strange. While I'm moving the pointer there is no problem, however if I don't, there is a noticeable lag when scrolling/opening a new tab for example, also the video problem I mentioned before. So it is not dependent on the content, but rather mouse input.
Comment 7 Pekka Paalanen 2017-06-19 08:15:31 UTC
Oh ok, that points to completely different kind of a problem: something about not flushing IPC messages out when they should, or hitting a blocking bug where one expects to read IPC events but they were already read by coincidence. Moving the pointer causes continuous IPC messages, which works around that kind of stalling problems. Does that sound like it, from a behavioural point of view?

It might be in Weston's XWM, or it might be in Xwayland, or the combination of the two.
Comment 8 Ilia Bozhinov 2017-06-19 09:03:58 UTC
Yes, I tried forcing weston rendering at 60fps(by always scheduling repaint right after the rendering), but the bug still persists, so probably the message to redraw(or whatever it is, I'm not familiar with xwayland) isn't sent on time or not fast enough.
Comment 9 Ilia Bozhinov 2017-12-26 20:01:06 UTC
Your suspicion from #5 is correct - I "patched" weston to use the window's own visual and colormap(in the case of chrome it is 24bit) and the slowness is gone, even though there are window decorations. Of course, shadows don't work because there is no alpha channel, but at least we know what the problem is. Perhaps this is some bug in Xwayland then.
Comment 10 GitLab Migration User 2018-06-08 23:55:31 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/wayland/weston/issues/93.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.