ghost
commented
5 years ago I've tried connecting to x11vnc via ssh forwarded tunnel and normally(directly, no tunnel), the same delays exist.
Closed ghost closed 5 years ago
ghost
commented
5 years ago I've tried connecting to x11vnc via ssh forwarded tunnel and normally(directly, no tunnel), the same delays exist.
ghost
commented
5 years ago pressing left Alt key multiple times doesn't repaint screen earlier than the 3 seconds it takes to show the first update
05/06/2019 07:58:23 3*Alt_L, calling: refresh_screen(0)
05/06/2019 07:58:23 4*Alt_L, setting: do_copy_screenWhat else I tried and had no effect so far:
x11vnc -noxdamage -display :0 -listen 192.168.0.63 -no6 -noipv6 -nonap -sb 0 -ping 1 -nofbpm -nowf -noxcomposite -noscr -allinput -fixscreen V=0.5,C=0.5,X=0.5,8=0.5 -speeds 300,100000,1 -wmdt xfce -nodpms -rfbport 46801 "$@"
Markus-N
commented
5 years ago I'm sorry I can't provide a solution ... only a "me too". And some additional infos: I'm also running ArchLinux, and the affected PC also has intel graphics. The difference is it occurred much later: 2019-08-20.
Here's my post in the ArchLinux forums: After update, x11vnc 5 seconds delay, sometimes freezes
bk138
commented
5 years ago 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?
bk138
commented
5 years ago Also, might this be related to #58?
Markus-N
commented
5 years ago 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.
Markus-N
commented
5 years ago Well ... I just tried downgrading xf86-video-intel to the previous version. Unfortunately no success.
bk138
commented
5 years ago Ok, let's try to sum things up:
I favour theory 2 at the moment. Please try:
Markus-N
commented
5 years ago 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: The affected PC is mostly remote-controlled vie vnc, but in all cases when I use it locally, it is as media player. It looks like the modesetting driver does not support hardware video decoding. Neither vlc nor mpv are able to play video after the config change. So modesetting can only be a temporary solution.
bk138
commented
5 years ago The affected PC is mostly remote-controlled vie vnc, but in all cases when I use it locally, it is as media player. It looks like the modesetting driver does not support hardware video decoding. Neither vlc nor mpv are able to play video after the config change.
What's your output of xvinfo? Mine (using modesetting on an Intel chipset and playing videos) says:
X-Video Extension version 2.2
screen #0
Adaptor #0: "GLAMOR Textured Video"
number of ports: 16
port base: 164
operations supported: PutImage
supported visuals:
depth 24, visualID 0x21
number of attributes: 5
"XV_BRIGHTNESS" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_CONTRAST" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_SATURATION" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_HUE" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_COLORSPACE" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 0)
maximum XvImage size: 8192 x 8192
Number of image formats: 2
id: 0x32315659 (YV12)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x30323449 (I420)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
Mine says
markus@vdr:~$ xvinfo
X-Video Extension version 2.2
screen #0
no adaptors presentSome more hardware info: I'm using a Celeron J3455 based power-saving mainboard (10 W TDP), because this PC is running 24/7. As the hostname says, it's running the VDR software (=Video Disk Recorder) and a few things more that regularly need to be looked after.
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).
bk138
commented
5 years ago Seems like an issue with your X.org config - ok to close this issue here?
Markus-N
commented
5 years ago 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.
ghost
commented
5 years ago I will check soon(ish)... FYI, I've been using a git version of xfwm4(close to 4.14), just in case the update 4.14 is the culprit.
ghost
commented
5 years ago UXA instead of SNA, either didn't apply or has no visible effect:
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. a) at the bash prompt, every 0.5sec there's a slight freeze)
Could be related to something i915 code does while lost connection with monitor, maybe see: https://bugs.freedesktop.org/show_bug.cgi?id=109522#c13 for an idea about what I mean here.
I'll try some things like i915.disable_power_well=0(and =1 even) soon.
Also, if I turn on F8->Options->Display->Scaling->Scale to window size(and Preserve Aspect ration is set too) in VNC-Viewer-5.3.1-Linux-x64 (3787248 bytes, sha256: 132a451376d085c0b60619e96a8f6449ceddfcf32d5f5d80ed678ba8bc136d7d), then the delay for each update is apparently 1 second on first(and 0.5 sec on subsequent ones?) instead of snappy. So this is just an unrelated but additional delay. But this is likely a VNC-Viewer or something else on the laptop issue, because the dropdown drawer/menu is also slow to open(animation wise) and VNC Viewer's using 88-94% CPU. But without scaling it's like 16-25 % CPU usage (that's one full core if it would be 100%, 400% would be all 4 cores, AMD laptop; seen via top). So I believe this particular delay can be brushed off / ignored.
btw, I'm running x11vnc like this(it's the last known variant of what I've tried since made the OP - but forgot why I've chosen all those settings):
x11vnc -noxdamage -display :0 -listen 192.168.0.78 -no6 -noipv6 -nonap -sb 0 -ping 1 -nofbpm -nowf -noxcomposite -noscr -fixscreen V=0.5,C=0.5,X=0.5,8=0.5 -nopw -input_eagerly -speeds 300,100000,1 -wmdt xfce -nodpms -rfbport 46801 on the i915 desktop which has now the resolution: 3840x2160
And the client, VNC-Viewer-5.3.1-Linux-x64, on a laptop with 2.3Ghz CPU, and Adapt to network speed was selected.
It's about 2.9-3.3MiB per second constant download, seen from client. Connection is 10MiB/sec capable(limited by the laptop LAN port), on a local LAN via a router that can do Gbps.
Now trying:
Driver "modesetting"and no AccelMethod set. (defaults to glamor the man says)
DoubleShadow not set.
Hmm, interesting...
Here's my xvinfo with modesetting:
X-Video Extension version 2.2
screen #0
Adaptor #0: "GLAMOR Textured Video"
number of ports: 16
port base: 91
operations supported: PutImage
supported visuals:
depth 24, visualID 0x21
number of attributes: 5
"XV_BRIGHTNESS" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_CONTRAST" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_SATURATION" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_HUE" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_COLORSPACE" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 0)
maximum XvImage size: 8192 x 8192
Number of image formats: 2
id: 0x32315659 (YV12)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x30323449 (I420)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)Now, with modesetting driver, I've noticed that even after turning off monitor the updates remained snappy until I exited and thus x11vnc was restarted and I connected again, then it's the same behaviour as with intel driver, which is: 3 second delay, then 1 second for subsequent updates.
Now let me try this: intel driver but don't disconnect after turning off monitor... ok it's still snappy until I disconnect!
So same behaviour with either intel or modesetting drivers ! hmmm.......
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:
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 +es are for when monitor was off and thus the 3/1 sec delay was at hand)
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!
ghost
commented
5 years ago So in conclusion, if x11vnc is started while monitor is off, the 3/1 sec delay is present. If monitor is turned on during the session, the delays are gone forever in that session even if the monitor is subsequently turned off(ie. physically turned off from the button) in that session. (true for me anyway) [note that exiting VNC Viewer aka the session, also exits x11vnc - if there's a way for this to not happen, I'm unaware of it!]
ghost
commented
5 years ago and it's freakin' xfwm4's fault! wow!
Literally in the same session, when x11vnc was started with monitor off, if I disable/enable xfwm4 compositor(via Start->Window Manager Tweaks->Compositor->[] Enable display compositing) the delay is gone / comes back respectively!!
(EDIT: Yan Pas has a nice way of enabling/disabling compositor via command line, like: xfconf-query -c xfwm4 -p /general/use_compositing -s false - or use true to enable, obviously)
So, starting x11vnc while the DisplayPort(at least?) monitor is turned off, and having xfwm4 compositor enabled, causes this 3/1 sec delay!
(now, to be fair, enabling compositor does enable transparency, but this is probably irrelevant)
local/xfwm4 4.14.0+5+ga9a98fb6-1 (builtbydaddy xfce4)
Thanks to @Markus-N for mentioning xfwm4 in: https://github.com/LibVNC/x11vnc/issues/102#issuecomment-524533322 I could not have found this out otherwise!!
bk138
commented
5 years ago @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?
ghost
commented
5 years ago 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:
git bisect start
git bisect good xfwm4-4.12.0
git bisect bad a9a98fb61db8eea95d6513695e2c871bc0000b62
latest(git commit) is bad too and it's: local/xfwm4 4.14.0+12+g99352a08-1so 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):
8fbff6ce0c097897a1f909dd02f72f4160f23d99 is the first bad commit
commit 8fbff6ce0c097897a1f909dd02f72f4160f23d99
Date: Tue Mar 24 21:04:17 2015 +0100
Implement vsync using OpenGL
Bug: 11642
configure.ac.in | 10 +-
settings-dialogs/tweaks-settings.c | 2 +-
src/Makefile.am | 3 +-
src/compositor.c | 357 +++++++++++++------------------------
src/screen.h | 25 +--
5 files changed, 149 insertions(+), 248 deletions(-)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... but I'm still trying...
I'm currently using local/xfwm4 4.12.0+21+g37527851-1 (builtbydaddy xfce4) until further notice.
Filed https://bugzilla.xfce.org/show_bug.cgi?id=15927
//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 Option "DoubleShadow" "true" but I forgot to test it last time!(and I've since rebooted, to say the least) - todo: retest/doublecheck if this is true. Ok, that wasn't it! true/false has no effect, also uxa/sna has no effect(if it even applies to modesetting!). I'm starting to question why modesetting driver now seems to get rid of the delay entirely, even though I'm using latest xfwm4 commit and compositor is on. This xfconf-query -c xfwm4 -p /general/vblank_mode shows auto and I haven't fiddled with it yet.
I'll recheck that later.(todo) FOUND IT: modesetting xorg driver with AccelMethod glamor (or if this AccelMethod setting is missing, which then defaults to glamor according to man modesetting) is causing the 3/1 delay, but no delays if AccelMethod is none or any other string than glamor which is probably interpreted as none(because man page says only none and glamor are supported). So that explains everything above. Basically glamor is opengl stuff and likely using vsync.
For now, using Olivier's suggestions with intel driver(and/or with modesetting driver with glamor acceleration method only), only vblank_mode=off gets rid of the delay (and using latest xfwm4 git commit), while Enable display compositing is enabled! So, auto, glx and xpresent are causing that 3/1 delay, but with off (as Olivier recommended) x11vnc is as snappy as ever.
ghost
commented
5 years ago 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 x11vnc was started (and the VNC Viewer client connects to it)while the monitor was physically turned off.
To get rid of the delay, find some way to turn vsync off, even while the 3/1 delay occurs during the current session.
The 3/1 delay happens when:
[1.] an xfwm4 version at least equal to 4.12 commit 8fbff6ce0c097897a1f909dd02f72f4160f23d99 is running and compositing is enabled (via Start->Window Manager Tweaks->Compositor->[] Enable display compositing OR running xfconf-query -c xfwm4 -p /general/use_compositing -s true - note: no xfwm4 restart required)
AND vsync is enabled eg. any of the below:
[a)] using intel driver with (at least) sna or uxa acceleration modes. (AccelMethod)
[b)] using modesetting driver with glamor acceleration mode. (AccelMethod)
Note: vsync is enabled if [a)] or [b)] and running xfconf-query -c xfwm4 -p /general/vblank_mode shows one of: auto, glx, xpresent (at least?), and vsync is disabled if it shows off.
The delay does NOT happen(ie. no delay) when:
[2.] when [1.] and any of the above [a)] or [b)] is true AND vsync is disabled (via xfconf-query -c xfwm4 -p /general/vblank_mode -s off and then restart xfwm4 eg. pkill xfwm4$ in xfce should auto-restart it(most of the time))
OR
[3.] when [1.] and:
[c)] using modesetting driver with none AccelMethod.
[4.] running an xfwm4 version younger than commit 8fbff6ce0c097897a1f909dd02f72f4160f23d99 and any of the above [a)] or [b)] are true. (with vblank_mode on auto so assumed on, though unsure if it actually worked tbh)
[5.] any xfwm4 with compositing disabled (ie. via Start->Window Manager Tweaks->Compositor->[] Enable display compositing OR running xfconf-query -c xfwm4 -p /general/use_compositing -s false - note: no xfwm4 restart required)
In retrospect all this ^ is a little convoluted, feel free anyone to make a new (concise)summary.
Thanks to Olivier Fourdan who suggested the vsync off solution here. Much appreciated!
Other thank yous can be seen here
PS: Start->Window Manager Tweaks is actually the command xfwm4-tweaks-settings
bk138
commented
5 years ago Great writeup! Sooo, a solution would be to disable xfwm (other WMs too?) vsync on x11vnc start? (Is this possible wtihout a xfwm4 restart?)
ghost
commented
5 years ago 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 */
}src/settings.c
Maybe it's enough to just include the tip(to turn off vsync) in the FAQ? imho
ghost
commented
5 years ago Can you cause this? TRACE ("window (0x%lx) has received a GTK_READ_RCFILES event", ev->window);
then xfwm4 will supposedly reload all prefs! "setting reload flag so all prefs will be reread at next event loop"
EDIT: command line causing ^ that here
or
"swapped-signal::notify::gtk-theme-name",
G_CALLBACK (set_reload), (gpointer) (display_info),
"swapped-signal::notify::gtk-font-name",
G_CALLBACK (set_reload), (gpointer) (display_info), hmm, let me try gtk theme change...
ghost
commented
5 years ago Great writeup! Sooo, a solution would be to disable xfwm (other WMs too?) vsync on x11vnc start? (Is this possible wtihout a xfwm4 restart?)
ok I found a way:
xfconf-query -c xfwm4 -p /general/use_compositing -s true
ghost
commented
5 years ago ignore that, I mistakenly pressed Ctrl+Enter and it posted it :)
ghost
commented
5 years ago Great writeup! Sooo, a solution would be to disable xfwm (other WMs too?) vsync on x11vnc start? (Is this possible wtihout a xfwm4 restart?)
ok I found a way to turn off vblank without restarting xfwm4, by causing a gtk GTK_READ_RCFILES event:
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:
xfconf-query -c xfwm4 -p /general/vblank_mode -s off
/tmp/gtkreload2and now to cause some event(?) without which the above has no effect:
xfconf-query -c xfwm4 -p /general/use_compositing -s false
xfconf-query -c xfwm4 -p /general/use_compositing -s true(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 vblank_mode)
(note: didn't use xfconf-query's -T aka toggle here, because it doesn't seem to work propely, ie. have to run -T four times to toggle twice, because sometimes it doesn't toggle and thus the value remains unchanged!)
fwiw, I'm using this on ArchLinux.
bk138
commented
5 years ago 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...
Wladastic
commented
4 years ago awesome that I found this. works great, plus when you disable the compositor display compositing in Window Manager Tweaks
antgel
commented
3 years ago @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?
AlamyLiu
commented
2 years ago July 2022 - I still hit the problem. Thanks to all the people already resolved the problem back in 2019. xUbuntu 22.04: x11vnc is still 0.9.16 lastmod: 2019-01-05.
alitaker
commented
2 years ago Same problem on Lubuntu 22.04: x11vnc: 0.9.16 lastmod: 2019-01-05 I'm using a dual input monitor, so cannot really test if the problem disappears when the monitor is connected to the server output
alitaker
commented
2 years ago Same problem on Lubuntu 22.04: x11vnc: 0.9.16 lastmod: 2019-01-05 I'm using a dual input monitor, so cannot really test if the problem disappears when the monitor is connected to the server output
Nevermind. I updated my vnc client and the problem disappeared :man_shrugging:
gwicke
commented
1 year ago 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 --auth guess. To enable the use for remote logins, I instead made sure that the XAUTHORITY env var was set to the correct path (in my case from lightdm). Debian package is tigervnc-scraping-server.
HerroBert
commented
1 year ago I have this problem too. Turned out, that mv Nvidia-Card put fps down to 1 when monitor is off. (test with glxgears) Temp. workaround: nvidia-settings --assign CurrentMetaMode="nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"
greatquux
commented
1 year ago 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
--auth guess. To enable the use for remote logins, I instead made sure that the XAUTHORITY env var was set to the correct path (in my case from lightdm). Debian package istigervnc-scraping-server.
Wow, I've been suffering with x11vnc performance for years, never knew about this server, and it works so much better, thank you!
jhnlmn
commented
1 year ago @ghost is this post specific to xfce, which is an alternative desktop environment? But I have several plain vanilla Ubuntu installs with "ubuntu:GNOME" desktop environment and none of the solutions discussed above works : there is no xfwm4, no Window Manager Tweaks. What should I do?
lucasew
commented
1 year ago 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.
JHale716
commented
3 weeks ago 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... unset DISPLAY
Don't know what the field was before so use at your own risk.
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%.