Im am using Debian 8 on an ASUS 64-bit machine. The issue is regarding dragging the side of the Terminal Emulator to resize the window. On initial drag, the window does not follow the mouse. After a second, it snaps to meet the mouse and then follows correctly as long as you move the mouse slowly. If the drag speed is increased, the glitch returns. The glitch displays a grey, pixelated background over the true background.. and also causes the pixel display size label in the middle of the terminal to break and trail across the screen
Is that with the compositor enabled? What version of Xorg and which video driver?
First I wanted to apologize, as I was confused between my 2 machines. The one with the bug is actually running Mint 17, not Debian 8. My Debian machine works fine. It happens with the compositor on or off, although there is less of a glitchy trail with it on. Here is the output of my dpkg for the core xorg packages: ii xorg 1:7.7+1ubuntu8.1 amd64 X.Org X Window System ii xserver-xorg 1:7.7+1ubuntu8.1 amd64 X.Org X server ii xserver-xorg-core 2:1.15.1-0ubuntu2.7 amd64 Xorg X server - core server Here is some video info: joe@joe-Q500A ~ $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) joe@joe-Q500A ~ $ find /dev -group video /dev/video0 /dev/fb0 /dev/dri/card0 /dev/dri/controlD64 joe@joe-Q500A ~ $ glxinfo | grep -i vendor server glx vendor string: SGI client glx vendor string: Mesa Project and SGI OpenGL vendor string: Intel Open Source Technology Center Hope that helps.
(In reply to Joe Parrilla from comment #2) > First I wanted to apologize, [...] No worries :-) > It happens with the compositor on or off, although there is less of a > glitchy trail with it on. Then it's not the window manager... The applications are responsible for tedawing their content on expose/configure notify events, what you describe here is either the apps or the X server/driver not being able to keep up with the events.
I see. Any ideas on how I can track down the root cause? I would love to figure it out and attempt a fix.
(In reply to Joe Parrilla from comment #4) > Any ideas on how I can track down the root cause? I would love to figure it > out and attempt a fix. - Does this happen only terminal or just any window? - Does this happen with all types of terminals out there (e.g. gnome-terminal, xterm, rxvt, konsole, etc.) or just one? - if just one, might be a bug/regression in teh termina lwidget used by that particular terminal. - While you resize, which process shows up on top of "top" as CPU usage? - I'm not sure which version of the Intel driver you have, maybe try to update the intel driver? Most distributions ship a snapshots of version 2.99.xxx of the driver, which is still under development, so maybe there is a bug/regression for you hardware in that particular version. - Maybe try a different accel. method for the intel driver (UXA vs. SNA) And at last: - You may want to disable opaque resize, and with the compositor enabled, you'll get a nice semi-transparent frame instead during resize. - You may want to try another window manager to see if the same problem occurs.
It only appears to be happening with the 'Terminal Emulator'. Xfce Terminal as well as all other windows seem to be OK. Xorg is taking a bunch of CPU when I resize... here is my top output (Xorg is the most consuming by a lot): PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1527 root 20 0 489020 54580 45344 S 20.6 0.7 0:30.62 Xorg Seems to be isolated to this specific emulator application. I think it is obvious this is not an XFCE bug. Thanks a lot for the advice. I can continue to figure this out given your advice. Thanks Olivier.