DRC <[email protected]> writes: > On 9/14/21 2:18 PM, [email protected] wrote: >> ** observations turbovnc 2.2.80 20210901 >> [2021-09-14 tis] >> fc34 server and client, hp laptop client with touch screen and stylus >> - Drawing with finger and drawing with mouse gives different line >> width in Inkscape > > Does this happen when using the application locally without TurboVNC? > Did it also happen with TurboVNC 2.2.6? Just trying to establish > whether it's a regression relative to the stable release of TurboVNC > or whether it's just a problem with our remote X Input feature in > general.
Please ignore this for a while, it is infuriatingly difficult to make a reproducible test case, since there are layers of bugs and quirks in each application(not necessarily turbovnc), I will see if I can sort something reproducible out. > > >> - Drawing remotely is kind of laggy, as compared with drawing >> locally. Im interested in seeing what can >> be done about this > > What is the bandwidth and latency of your network connection? Similar > question to above-- has this changed since 2.2.6 or has it always been > a problem? > > > I'll do what I can to fix bugs in the feature, but unfortunately the > remote X Input feature was developed under short-term contracts with a > couple of different companies, so there is no funding to make > functional improvements to it. I'd really like to get funding to > improve drawing tablet support for Windows clients as well (using > Windows Ink to support newer tablets, rather than the flaky and > obsolete WinTab API that the native Windows TurboVNC Viewer > supported.) It is a nice feature that makes Turbovnc stand out IMHO. The perceived lagginess has always been there. At the moment it is easier to see in Krita than in Inkscape, since something happened in cursor handling in turbovnc recently, but the effect is the same in both applications. This is my perception, not sure if correct: - Usually when you move the cursor, it is rendered locally, given the impression of smooth movement. nice. Acturally, though, the cursor events have to trave to the server and be handled there, and the results be sent back. This works really well for many use-cases. (note that this statement about the cursor movement doesnt really affect anything regarding the lagginess, it just makes it more obvious to the eye) - When drawing in Krita remotely, some different things are happening. Krita is xinput aware, and also wants to render the cursor. So, cursor movement and drawing is lagging somewhat, as compared with drawing locally. With "lagging" I mean I have to draw much slower when working remotely than I need to do when working locally, in order for the stroke to reach where the stylus is physically on the screen. I dont have any hard timings but lets say it takes 1/10th of a second for the stroke to reach the stylus remotely, whereas there is no perceived delay at all locally. I have tested this on a server that is in a datacenter, and also one that is on the same lan as the client. The perceived lagginess is roughly the same. I have done quite a bit of experimentation to see if I could find some kind of user level setting that could affect this perceived lagginess, but so far I haven't actually found anything. I just feel like it shuold be possible to reduce the lagginess, since the xinput data stream to the server cant be all that massive, and the perceived lagginess of something like a pinball game much lower. Anyway sorry for all the "perceived" statements, I dont have any way to generate hard data that I can think of. -- Joakim Verona [email protected] -- You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/87a6kekte2.fsf%40tanaka.verona.se.
