any1
Minor animations cause full window redraw in some applications
Thanks for the great project. I am using wayvnc to connect from a computer running Xorg to one running sway. This generally works well, but I have noticed one fairly significant issue.
When using certain applications, even minor animations cause the entire to be redrawn. For example, if I type this issue with a single sway window running qutebrowser, then the blinking cursor causes the entire qutebrowser window to be redrawn, and wayvnc --show-performace reports average frame damage: 95.9% (the other 4.1% corresponds to sway boarder and header, which are not re-drawn). If I split the screen into two windows, then the frame damage drops by half. These full-window redraws cause considerable visual issues (flashing and stuttering) and render the application essentially unusable.
This only happens for certain applications. Rendering a blinking cursor in Firefox, for example, does not cause high frame damage (in fact, it round down to 0.0%). I haven't done extensive testing with other application (I've only recently started using wayvnc) but would be happy to test any others you'd like or to provide more information about my hardware or software setup.
This isn't a breaking issue for me; avoiding applications that trigger full-window redraws is an acceptable workaround. But I thought you might want to know about the issue and I would be happy to provide any other info that would help resolve it.
The "average reported frame damage" is the frame damage that's reported from the application to sway and then from sway to wayvnc, neither sway nor wayvnc can do anything about that. This is why wayvnc also compares the reported damage region with the last frame so that we only send regions that have actually changed. This means that wayvnc spends some CPU time doing extra damage checks, but the damage check is pretty fast on my computer and does not cause any stuttering.
It would be good to know more things about your setup like: what sort of a computer is it, screen resolution, which vnc client are you using, have you turned on lossy compression in the client, did you compile wayvnc yourself or install from package, did you maybe enable a non-default feature, which version of sway are you running and which version of wayvnc?
Thanks for the quick reply and explanation. Answers to your questions are below:
what sort of a computer is it,
The computer I'm connecting to is a System76 Galago pro with an i7-8550U CPU and integrated Intel graphics (620); the client I'm connecting from is a ThinkPad T480 with an Intel i5-7300U CPU with integrated Intel graphics (620). Both computers are running Void Linux, though the client is running the glibc version and the 5.7.17 version of the kernel while the PC I'm connecting to is running the musl version and the 5.8.12 kernel. The client is using xorg-server v1.20.9 and the window manager StumpWM v2020.02.18
screen resolution
I have multiple monitors connected, both with resolutions of 1920x1080. I ran sway in headless mode; typically, I set its resolution to 1915x1070 (setting it to 1920x1080 oddly results in scrollbars). But I also tested without specifying a resolution to sway, which results in a "fullscreen" window that takes up ~50% of a monitor. This didn't have any effect on the issue.
which vnc client are you using
I am using TigerVNC v1.10
have you turned on lossy compression in the client,
I did not turn off the automatic lossy compression that TigerVNC performs when not passed the -AutoSelect=0 flag.
did you compile wayvnc yourself or install from package, did you maybe enable a non-default feature
I installed it from the Void package repo, which does not appear to enable any non-default features.
which version of sway are you running and which version of wayvnc?
I am using sway v1.5. wayvnc --version reports the following values: wayvnc: 0.2.0; neatvnc: 0.2.0; aml: 0.1.0.
I hope that info is helpful. Please let me know if you'd like me to try anything else and thank yo again for all your work on wayvnc.
My Galago Pro i5-10210U has no trouble with playing a fullscreen video using lossy tight encoding. lossless is a bit choppy though, but there's no blinking cursor. My Thinkpad T470s i5-6300U has no trouble either. Both are running arch linux with kernel version 5.8 and glibc. Maybe it has something to do with musl?
I guess I'd have to actually run void to figure this out. Do you know how to use perf?
@codesections : Its been a while since this issue was opened... Is this still an issue?
