How to get rid of the 3 second delay ? #102
Comments
|
I've tried connecting to x11vnc via ssh forwarded tunnel and normally(directly, no tunnel), the same delays exist. |
|
pressing left Alt key multiple times doesn't repaint screen earlier than the 3 seconds it takes to show the first update |
|
What else I tried and had no effect so far: |
|
I'm sorry I can't provide a solution ... only a "me too". And some additional infos: Here's my post in the ArchLinux forums: After update, x11vnc 5 seconds delay, sometimes freezes |
|
Hi @Markus-N, could you try git-bisect (https://git-scm.com/docs/git-bisect) in order to find the change that might have introduced the lag? |
|
Also, might this be related to #58? |
|
Hi @bk138, yes, I can do that but I need some advice what to look for. As I wrote in the ArchLinux forum, the system update that introduced the issue to me did not include x11vnc. Instead, it came with a new intel x11 driver, so my suspicion is that there is some incompatible change there. In this update, XFCE was also updated from 4.12 to 4.14, including a new window manager (xfwm4). This could also be the culprit. I just checked the log of the package manager. The last update of x11vnc and libvncserver was in January 2019. Versions:
I've also checked #58. And yes, it could be related. Looking a bit closer at the "frozen" state I sometimes get, it is indeed a flicker between two screenshots. In #58, wayland is also mentioned. But as a user of XFCE, I can not switch to wayland because they don't support it yet. |
|
Well ... I just tried downgrading xf86-video-intel to the previous version. Unfortunately no success. |
|
Ok, let's try to sum things up:
I favour theory 2 at the moment. Please try:
|
|
Hi, I have just tried both options.
For both tests, I've checked /var/log/Xorg.0.log to see that my configuration changes were effective. This problem is solved, but the switch to modesetting introduces another one: |
What's your output of |
|
Mine says Some more hardware info: According to the datasheet, the builtin GPU is a "Intel HD-Graphics 500". I'm remote-controlling it e.g. from work (via a reverse ssh tunnel), and locally I'd like to watch the recorded TV shows and clips downloaded via MediathekView (mostly x264 encoded .mp4). |
|
Seems like an issue with your X.org config - ok to close this issue here? |
|
I'm not the one who can decide this: I don't know if this solution also works for @howaboutsynergy. Also, I'm not sure what else I will lose by not being able to use the intel driver anymore. |
|
I will check soon(ish)... |
|
UXA instead of SNA, either didn't apply or has no visible effect: Before:
After:
(those are the only What I've seen is that the 3sec delay is present iff my monitor is off. (AND only after x11vnc is restarted during monitor off, given the below findings) I turn monitor on, and it's pretty snappy! (multiple updates per second, seems like it's normal but if I hold a key down(eg. Also, if I turn on btw, I'm running Now trying: and no Hmm, interesting... Now, with So same behaviour with either The monitor is connected to the motherboard DisplayPort (mobo is ASUS Prime Z370-A, cpu is Intel i7-8700K). Here's output of x11vnc during the monitor on(snappy updates), then monitor off(sluggish, 3 sec/ 1 sec updates) states: monitor is on: (ignore monitor is off: The only relevant diff I see is: +check_xrandr_event():
+Detected XRANDR event at location 'check_xevents':
+check_xrandr_event: no change detected.
+check_xrandr_event: enabling full XRANDR trapping anyway.
+check_xrandr_event():
+Detected XRANDR event at location 'check_xevents':
+ serial: 198
+ timestamp: 8328878
+ cfg_timestamp: 8906092
+ size_id: 65535
+ sub_pixel: 0
+ rotation: 1
+ width: 3840
+ height: 2160
+ mwidth: 1016 mm
+ mheight: 571 mm
+
+check_xrandr_event: previous WxH: 3840x2160
+check_xrandr_event: no change detected.
+check_xrandr_event: updating config...
+check_xrandr_event: current WxH: 3840x2160
+check_xrandr_event(): returning control to caller...and some line moved: Client Protocol Version 3.8
Protocol version sent 3.8, using 3.8
rfbProcessClientSecurityType: executing handler for type 1
rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8
-copy_tiles: allocating first_line at size 121
rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000016)
rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000015)
rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x0000000F)
@@ -105,7 +132,6 @@ Pixel format for client 192.168.0.77:
true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
no translation needed
client_set_net: 192.168.0.77 0.0002
+copy_tiles: allocating first_line at size 121
created selwin: 0x120007c
called initialize_xfixes()(the Ok now, if I exit VNC Viewer and thus x11vnc gets restarted while monitor is off, then reconnect VNC Viewer, see that the 3/1 sec delay is still present then go and turn on the monitor, the delays are now gone, and the full output is: now in that same session(so no x11vnc restart / VNC Viewer exit) if I turn off the monitor, the snappiness remains! |
|
So in conclusion, if |
|
and it's freakin' So, starting x11vnc while the DisplayPort(at least?) monitor is turned off, and having (now, to be fair, enabling compositor does enable transparency, but this is probably irrelevant)
Thanks to @Markus-N for mentioning xfwm4 in: #102 (comment) |
|
@howaboutsynergy very nice finding! What do you think, how should we proceed from here? Add a note to the README? Detect xfwm4 if possible an issue a runtime warning? |
|
I'm bisecting xfwm4 for now... so I can't recommend anything yet. EDIT: I mean, since I've already confirmed(for myself) that good/bad/latest are true: so it's just a matter of time until we find the culprit =) I'm already beyond happy! Meanwhile I noticed a 2/1 delay if I simply enable 80%/80% scaling with aspect ratio on, whilst simply disabling scaling returns it to normal snappy speeds!(so it's worth noting). 2/1 delay is 2 seconds for first update and then 1 second for each subsequent updates.(this is probably due to VNC Viewer itself, my guess) EDIT2: bisecting shows(and I double checked that it is indeed the problem commit): https://bugzilla.xfce.org/show_bug.cgi?id=11642 I can't really figure out how to revert that commit on top of the latest git... I'm currently using //What the?! I can't reproduce this anymore using latest xfwm4 commit(of Aug 29th)... I wonder what I'm missing, checking... Oh I know why! I've set modesetting driver and For now, using Olivier's suggestions with |
|
Ok gents, here's the conclusion(which is, at least, true for me): tl;dr: The 3/1 second delay is caused by vsync(aka vblank) being turned on, but this delay is only in effect when The 3/1 delay happens when: Note: vsync is enabled if [a)] or [b)] and running The delay does NOT happen(ie. no delay) when: In retrospect all this ^ is a little convoluted, feel free anyone to make a new (concise)summary. Thanks to PS: |
|
Great writeup! Sooo, a solution would be to disable xfwm (other WMs too?) vsync on x11vnc start? (Is this possible wtihout a xfwm4 restart?) |
Doesn't seem like it's possible without xfwm4 restart. I'm guessing xfwm4 reads that property only once at startup and that's why. I say this because it works in realtime for enabling/disabling compositing without restart. But I wouldn't necessarily recommend that x11vnc attempt to disable vsync itself. Maybe make it an option, if so? Because I imagine, if someone's watching movies looking at the directly at the physical monitor on that computer where x11vnc runs, but also wants to vnc to it(or allows others to) without wanting to disconnect for the duration of the movies, for whatever reason, then the movies will tear like crazy during that vnc session. Of course this assumes that vsync is disable only when someone connected. I say that maybe make it an option since this delay only happen when monitor is physically off, for me anyway, so then, for anyone else whose monitor is always on, they might need/want vsync. Still, I've no idea how to disable vsync without xfwm4 restart... else if (!strcmp (name, "vblank_mode"))
{
/* This property is set at startup only */
}
Maybe it's enough to just include the tip(to turn off vsync) in the FAQ? imho |
|
Can you cause this? or hmm, let me try gtk theme change... |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ok I found a way to turn off vblank without restarting xfwm4, by causing a gtk First, have this: #!/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
}
reloadGTKThen run it after disabling vblank: and now to cause some event(?) without which the above has no effect: (doesn't have to be compositing toggling here, this is just to cause some xfwm4 event or something - frankly I don't even know, but all this is just from reading xfwm4 source code from fwiw, I'm using this on ArchLinux. |
|
Mhh, I think we should rather mention this in the README and maybe add a link to this issue (or add your script to the 'misc' directory... |
|
awesome that I found this. |
|
@ghost Great thread although I can't confess that I understood every last word. I'm an XFCE user, and following this I found that turning the monitor on fixed the problem for me, even with compositing on. Is there a solution for me other than leaving the monitor on all the time i.e. disabling power management? Is the monitor on/off related to the vblank? If so, can I keep vblank permanently set as necessary by running the script when the monitor is off? |
|
July 2022 - I still hit the problem. Thanks to all the people already resolved the problem back in 2019. |
|
Same problem on Lubuntu 22.04: x11vnc: 0.9.16 lastmod: 2019-01-05 |
Nevermind. I updated my vnc client and the problem disappeared 🤷♂️ |
|
An alternative solution that works for me without compositor / opengl related issues is x0vncserver, part of TigerVNC. It supports mostly the same options as x11vnc, except for |
|
I have this problem too. Turned out, that mv Nvidia-Card put fps down to 1 when monitor is off. (test with glxgears) |
Wow, I've been suffering with x11vnc performance for years, never knew about this server, and it works so much better, thank you! |
|
@ghost is this post specific to xfce, which is an alternative desktop environment? |
|
Had this problem on NixOS I only stopped picom (my compositor) and problem solved I actually only use a compositor in my setup because of vsync, that solves tearing. |
|
I had this problem on a clean build of Mint 22; trying something else that didn't work, I unset Display and it solved the slowness... |
The first update(scroll, type) seems to be shown only after 3 seconds but the next ones are after/at 1 second apart. Why does this happen? Can some settings make this smoother? in the miliseconds range?
EDIT: jump to workaround.
I'm on ArchLinux, running x11vnc on a Desktop computer with Intel i7 8700K processor.
local/x11vnc 1:0.9.16-1
I'm starting it from within a ssh session, via a script, but here's the relevant part:
Viewers tried:
CPU usage on the viewer(a Laptop) doesn't even register on
topso it's like under 1%.The text was updated successfully, but these errors were encountered: