xorg-server - GIT Commit - 25344ba7f7845654364d62bf15322b3b79465bd9 Use KDE 3.5.10 as the window manager. When Xdmx is started across multiple computers, moving windows across multiple machines / resizing windows works fast. Everything then slows down over time until you finally notice that is almost unbearable how long it takes to simply move a while around or resize it. At that point, when new windows launch and appear on the local display (the display that Xdmx is running on), they run fine. As soon as you move then onto a display attached to a different computer - they get terribly slow. What I mean by terribly slow, is you move the window a little bit and wait several seconds at least for the screen to re-draw. Move it a little bit more and wait same amount of time. Move it a lot and wait same amount of time. Resize the window any amount and wait the same amount of time. Kill Xdmx and restarting Xdmx and KDE resolves the problem for a short while until it slows down again. I recall this same behaviour from the xorg-server 1.3 (X.Org 7.2 I think?) days as well.
Actually, this doesn't require KDE. Just long periods of use. I will attach two log files - one profiling Xdmx just after startup, and another profiling it again after it has slowed down considerably.
Created attachment 30595 [details] opreport output after starting Xdmx
Created attachment 30596 [details] opreport output after Xdmx has become very slow
Created attachment 30612 [details] show how long miMoveWindow ran Here's an interesting development. I made the attached changes to xorg-server to help narrow down the ever increasing slowness of Xdmx.... After several hours of usage...depending on the application window that I'm moving across screens, I'm seeing over 100,000 micro seconds of processing time of miMoveWindow on roughly 1 of every 5 or 6 calls of that function. The more "heavy" programs like TaskJugglerUI, KWrite, etc... I'm seeing well over 300,000 micro seconds.
Created attachment 30632 [details] squashed debugging statements Events on non-input backend displays are accumulating causing the slowness over time. This patch applies to GIT Commit 1228e2d052f0bb98175c55c194340773b5fedb40. It shows the call stack (# of calls, and processing time). It clearly shows the slow down when run and how many events are in the queue that keep getting re-processed.
Created attachment 30634 [details] temporary patch to prevent MotionNotify events from piling up I'm providing this in case anyone needs it until the real fix is found.
So it sounds like this isn't an issue of the server slowing down "over time" but rather as it gets backlogged. Once you let the backlog clear, performance returns, right? What is your networking configuration? Is it possible that the network is causing the bottleneck?
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
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.