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.
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).
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
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 /tmp/gtkreload2 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: ``` #!/bin/bash #src: https://crunchbang.org/forums/viewtopic.php?pid=428525#p428525 function reloadGTK(){ python2 - <<END import gtk events=gtk.gdk.Event(gtk.gdk.CLIENT_EVENT) data=gtk.gdk.atom_intern("_GTK_READ_RCFILES", False) events.data_format=8 events.send_event=True events.message_type=data events.send_clientmessage_toall() END } reloadGTK ```
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).
(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.
-- 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