! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
x11vnc is very laggy due to commit 8fbff6ce0c097897a1f909dd02f72f4160f23d99


Description QDeKIFHFSzq4Uyvj7U 2019-09-05 06:26:47 CEST
commit 8fbff6ce0c097897a1f909dd02f72f4160f23d99

Date:   Tue Mar 24 21:04:17 2015 +0100

    Implement vsync using OpenGL
    Bug: 11642
it references https://bugzilla.xfce.org/show_bug.cgi?id=11642

Coming from https://github.com/LibVNC/x11vnc/issues/102 where I found out that during a VNC Viewer connection(from laptop) to an x11vnc(on desktop), 
in the same vnc session(ie. without disconnecting), in the case when x11vnc was started while the monitor was off (required), if I disable/enable xfwm4 compositor(via Start->Window Manager Tweaks->Compositor->[] Enable display compositing) the x11vnc lag* is gone / comes back respectively!!

*The lag or delay refers to there being a 3 second delay in updating the screen(seen on the VNC Viewer side) the first time when pressing a key or moving a window, and then any subsequent updates taking 1 second each, until you stop giving any inputs for a few seconds(1-2sec?) then the same 3/1 delay can start again on any new input.

I'm currently using xfwm4 4.12 commit 37527851e4e957dc23562f99d5d81cca186d9537 to work around this issue(ie. no delay), because that commit is what `git log 8fbff6ce0c097897a1f909dd02f72f4160f23d99~1` shows(ie. the previous commit before the bad commit? even though I can't get any form of `git log $args` to show them to me in consecutive order; so maybe I'm wrong about it being the previous? or I don't know)

I wasn't able to figure out how to revert the "bad" commit(as bisect called it) on top of latest git, but even latest git xfwm4 causes that same x11vnc delay.

This happens with `modesetting` driver as well as with `intel` driver, in xorg configs.
Comment 1 Olivier Fourdan editbugs 2019-09-05 08:55:22 CEST
You don't need to revert that commit, just switch to another vblank method such as Xpresent (or switch it off entirely).

 * off:

     $ xfconf-query -c xfwm4 -p /general/vblank_mode -s off

 * xpresent: 

    $ xfconf-query -c xfwm4 -p /general/vblank_mode -s xpresent

 * glx:

    $ xfconf-query -c xfwm4 -p /general/vblank_mode -s glx

Note: You need to restart xfwm4 for the change to be taken into account.

You can also, for testing purpose, change the vblank mode from the command line, it won't be saved though (useful for testing):

 * off:

     $ xfwm4 --replace --vblank=off

 * xpresent: 

     $ xfwm4 --replace --vblank=xpresent

 * glx:

     $ xfwm4 --replace --vblank=glx

The default is GLX because not all drivers support Xpresent, and also because Xorg 1.20 had a bug that would prevent to work reliably, but clearly my preference on intel would be Xpresent.

With VNC, I'd say do not use vsync (i.e. turn it off).
Comment 2 QDeKIFHFSzq4Uyvj7U 2019-09-05 13:11:47 CEST
Impressive and very helpful info! Thanks so much Olivier!

I've found that turning off vsync completely was the only way to get rid of that 3/1 delay.
So I successfully used the following: `xfconf-query -c xfwm4 -p /general/vblank_mode -s off ; pkill xfwm4$`

`xpresent`, `glx`, `auto`  with either `intel`(uxa or sna accel) or `modesetting`(with `glamor` accel) drivers had no effect on the x11vnc delay, thus as you've recommended `With VNC, I'd say do not use vsync (i.e. turn it off).` was the solution! Cheers!

Note that, on xfce, if I run this `xfwm4 --replace --vblank=off` but then C-c it, xfce(or something:D) will auto-restart `xfwm4` with `--replace --vblank=off` args to which it also appends the usual: `--display :0.0 --sm-client-id someGUIDhere`. Not sure how/why it remembers them, possibly true only in this session only(so they won't be remembered after I exit `startx`). But I'm sure it has something to do with Start->Session and Startup -> Current Session -> xfwm4 Restart Style immediately
Comment 3 QDeKIFHFSzq4Uyvj7U 2019-09-05 14:28:28 CEST
Apparently there's a way to turn off vsync without restarting xfwm4, I've tested this to work:

xfconf-query -c xfwm4 -p /general/vblank_mode -s off
xfconf-query -c xfwm4 -p /general/use_compositing -s false
xfconf-query -c xfwm4 -p /general/use_compositing -s true

This is very crude, would there be a better way?

gtkreload2 is:


#src: https://crunchbang.org/forums/viewtopic.php?pid=428525#p428525

function reloadGTK(){
python2 - <<END
import gtk

data=gtk.gdk.atom_intern("_GTK_READ_RCFILES", False)


Comment 4 powerman-asdf 2020-02-26 02:09:52 CET
In xfwm4-4.14.0 with `use_compositing=true` and `vblank_mode=auto` x11vnc doesn't update screen at all. I.e. after connect it show desktop and then receive no updates. Accordingly to x11vnc hint this should be fixed by adding -noxdamage option, but it doesn't helps:

 X DAMAGE available on display, using it for polling hints.
   To disable this behavior use: '-noxdamage'
   Most compositing window managers like 'compiz' or 'beryl'
   cause X DAMAGE to fail, and so you may not see any screen
   updates via VNC.  Either disable 'compiz' (recommended) or
   supply the x11vnc '-noxdamage' command line option.

To fix this I need to change either `use_compositing=false` or `vblank_mode=off`.

4.12 didn't have this issue (probably because it doesn't enable compositing by default).
Comment 5 Olivier Fourdan editbugs 2020-02-26 09:01:56 CET
(In reply to powerman-asdf from comment #4)
> In xfwm4-4.14.0 with `use_compositing=true` and `vblank_mode=auto` x11vnc
> doesn't update screen at all. 

Using "--vblank_mode=auto" with software rendering basically means Xpresent which is unlikely to work with VNC, that's why I suggested using "--vblank=off" (there is no such option "vblank_mode" in 4.14) - But you don't need to turn compositor off for VNC.

> 4.12 didn't have this issue (probably because it doesn't enable compositing by default).

4.12 did not have this problem because it did not have any real vblank control.
Comment 6 Git Bot editbugs 2020-05-29 12:29:52 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/348.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #15927

Reported by:
Reported on: 2019-09-05
Last modified on: 2020-05-29


Olivier Fourdan
CC List:
2 users


GIT Master


Additional information