I was trying to figure out why I was getting microstutters in some games after upgrading to 5.5. I then toggled compositing a few times and at some point I managed to get a black square to appear where Dropbox usually is in the system tray. That I was in a fullscreen game and this window was trying to draw itself above the game seemed suspicious. I killed xembedsniproxy and sure enough the problem was resolved. Reproducible: Always Steps to Reproduce: 1. Ensure KWin is set to "Suspend compositor for full screen windows" 2. Ensure xembedsniproxy is running 3. Open an SDL2 app in fullscreen mode (example: latest version of Quakespasm) 4. Notice lots of microstuttering regardless of whether the in-game vsync is enabled or disabled 5. Kill xembedsniproxy 6. Reopen the same SDL2 app and notice that it runs smoothly now. Actual Results: Lots of microstutter, running without in-game vsync gives uneven framerate and no tearing Expected Results: In-game vsync off should give tearing, in-game vsync on should be butter smooth I tried forcing xembedsniproxy to Keep Below in the KWin rules but no dice.
I asked the KWin maintainer, he didn't have any ideas. I have some questions What apps were in the X tray? were they repainting (updating?) Does that make a difference? Do things slow down if you just disable compositing manually?
Hi, a few points of clarification (forgive me if this isn't new information): The cause of the bug is most likely XEmbedSNIProxy, not KWin. Also, more specifically, the issue isn't "slowdown" but microstutter. If I have compositing running then it's impossible for me to get a smooth 60 FPS without microstutter (usually at least a couple dropped frames a second), likely because the contents have to go through both nVidia's VSync and KWin's VSync, which are not perfectly synchronized with each other. If I want a smooth display, I have to run games full-screen and unredirected. My hope is that in the future, Wayland, new nVidia drivers and/or a new version of KWin will finally solve microstutter in windowed applications. However, I do not know where I would file such a bug because I do not know where the fault lies in the current graphics stack. For now I would at least like to be able to run applications full-screen without microstutter. I need unredirection for that. To answer your questions: - Dropbox is the only X icon in the tray. - The icon was not repainting to my knowledge. It was not animating, and KWin's Show Paint effect did not reveal any painting related to this icon. - Disabling compositing resolves microstutter but I don't want to Alt + Shift + F12 or make a KWin rule for every game I play. My understanding is that SDL2 only does unredirected fullscreen when there are no windows on top. Is there some sort of stray X window that XembedSNIProxy has that is sticking to the top, or is somehow trying to paint itself above everything else? This is my best guess as to what's going on. My current workaround is to prevent xembedsniproxy from running at login.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
I was not aware that removing NEEDSINFO had to be done manually by the reporter.
Hi Danni H, This bug is quite old, but maybe you are still there and can answer few questions: 1. Are you still experiencing microstutters? 2. If yes, does it happens always when xembedsniproxy is running or only when it is rendering some icons? Dropbox no longer uses XEmbed, you need to test with different application, for example: xchat, tuxguitar, hexchat, liferea or any app via Wine. For each XEmbed system tray icon, xembedsniproxy creates new window. It should be always in the background, but if you saw black square that was probably it.
Hi, This is indeed a pretty old bug and the behavior of KWin has changed since I filed this issue. It no longer automatically suspends compositing for topmost fullscreen windows (which I personally consider a regression, but that's for another issue). Instead the application requests that compositing is disabled. So even if some other window might otherwise interfere, KWin will still turn off effects until the application is closed, even if it opens in a window rather than fullscreen. I would still like to do a bit of testing with this. Namely, whether other windows can interfere with the graphics driver's ability to present the application using flip mode instead of blit mode - on the proprietary nVidia drivers the application must be topmost fullscreen with compositing disabled for this to happen. There is a helpful "API indicator" option that shows the current presentation mode. I'll let you know what I find.
Hi, Some information on unredirection I found in a KWin fork that's focused on low latency and removing tearing and stuttering: https://github.com/tildearrow/kwin-lowlatency/blob/Plasma/5.15/unredirect.md I would strongly recommend getting in touch with the author of this repository so that the KWin experience can be improved for everyone. This is especially important given the rise of Variable Refresh Rate tech that will require fixes to how KWin handles its timing. GNOME ahead of KDE with high-refresh rate monitors, smoother, less lag and stutter: https://www.reddit.com/r/kde/comments/brsmqc/gnome_still_handles_highrefresh_rate_monitors/ Will the developers understand the severity of sync issues in KWin, or will they be left to rot like all the other bugs in the KDE Bugzilla?
I'm sure KWin developers are aware of this lowlatency project. It looks that it is not flawless neither, especially combined with Wine. BTW. I'm not a KDE developer, I was annoyed by one issue in XEmbedSNIProxy so... I fixed that (and few other issues as well). This is how it works... I'm closing this one. Please create new one for XEmbedSNIProxy if there is an issue with it. You can also open a bug for KWin component and start discussion there (but better check mailing list first: https://mail.kde.org/mailman/listinfo/kwin)
We are aware of that fork. To give some background on what you were originally seeing: - X, when not compositing, if given only a full screen window will take a short path and flip that surface directly to the buffer - That won't work if knows there are other windows. Which could be xembedsniproxy as you suspect - Kwin is not involved in any of that, if compositing is disabled. Unredirection is like a mini version of not-compositing for that one window, but if xembedsniproxy is an issue in the former case it will be here. >or will they be left to rot like all the other bugs in the KDE Bugzilla? Don't be antagonistic. >I'll let you know what I find. I am waiting on this. xwininfo -tree -root would be the most useful, I can't see why our z-stack would be rasied when a game is in focus.
Created attachment 124789 [details] xwininfo output
> Don't be antagonistic. My bad. I shouldn't have let my frustration get to me. I'm happy that there is awareness of these issues among the KWin developers. > xwininfo -tree -root would be the most useful, I can't see why our z-stack > would be rasied when a game is in focus. This issue seems to be fixed but regardless I have attached the output of xwininfo while running hexchat and GZDoom, with GZDoom fullscreen and in the foreground.