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?

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.

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)

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.

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.

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.

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.

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.

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.

-- 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.