Bug 7252 - automatic composited windows can fail to update
Summary: automatic composited windows can fail to update
Status: CLOSED DUPLICATE of bug 5241
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: 1.3.1
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.10.0
Assignee: Pierre Ossman
URL:
Keywords: samuel_tester
Depends on:
Blocks:
 
Reported: 2018-09-20 16:17 CEST by Pierre Ossman
Modified: 2018-09-27 14:28 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2018-09-20 16:17:53 CEST
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).
Comment 1 Pierre Ossman cendio 2018-09-20 16:34:35 CEST
Upstream report and patch:

https://bugs.freedesktop.org/show_bug.cgi?id=108005
Comment 2 Pierre Ossman cendio 2018-09-20 16:42:32 CEST
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.
Comment 5 Pierre Ossman cendio 2018-09-21 09:57:27 CEST
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.
Comment 6 Samuel Mannehed cendio 2018-09-27 11:26:25 CEST
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.
Comment 8 Pierre Ossman cendio 2018-09-27 14:28:48 CEST
Release notes removed. Marking as duplicate.

*** This bug has been marked as a duplicate of bug 5241 ***

Note You need to log in before you can comment on or make changes to this bug.