I am seeing delays in xfce4-terminal, and some times it doesn't update at all until I do some more action (e.g. move the mouse).
After some digging it turns out that this is because of some bad interaction between the Composite extension and the VNC code:
Some windows can be implicitly composited. Generally this is because the window was created with a visual that is incompatible with the root window (the "screen"). So Composite steps in to automatically convert and update things whenever the contents of the window changes.
The way it does this is to register a "block handler" that can do the conversion an updating. A block handler is a mechanism used to prepare which file descriptors you want monitored, and the timeout you want for select()/poll().
The reason it breaks is because Composite's block handler might be run after VNC's block handler. So VNC ran first and didn't see any work to do so it set an infinite timeout. After that Composite ran and updated the display. VNC noticed this and set up a timer to update the client(s). However its block handler had already executed so it newer got a chance to tell the X core that it wanted a short timeout.
The end result is that the X server went to sleep until something external made it wake up. At that point VNC got a chance to run again and push the updates to the client(s).
Upstream report and patch:
Scenario that I used for testing:
1. Start xfce with compositing disabled in the window manager tweaks.
2. Start a xfce4-terminal and get enough output in it for it to be possible to scroll
3. Scroll a single click on the mouse wheel
At that point I end up with a situation where nothing on the screen changed. Moving the mouse or doing any other action gets the screen updated again.
Should be ready for testing. The test case in comment #2 can be used. I have not identified any other application suffering from this bug.
This bug has never affected our users AFAICT. I can not reproduce the bug with ThinLinc 4.9.0 nor with nightly build 5913.
I built the thinlinc-vnc-server rpm from revision r33718 (the revision before the fix for this bug) and could reproduce the issue. My conclusion is therefore that this bug started happening after the Xorg upgrade should be resolved as duplicate of bug 5241.
We also need to remove the release notes written for this bug in that case. Re-opening.
Release notes removed. Marking as duplicate.
*** This bug has been marked as a duplicate of bug 5241 ***