How can I test the 3.0 pre-release?

[joa...@verona.se]

Hello,

The 3.0 pre-release has several features that seems interesting for me,
like changes in xinput handling etc. OTOH, 2.2.6 is working pretty well,
so I'm wary of breaking this nice setup.

Do you have any hints on trying out the pre-release safely?

I'm running Fedora 34 on both client and server.
--
Joakim Verona
joa...@verona.se

[DRC]

Use the pre-release RPMs available here under "dev branch (3.0 evolving)":
https://turbovnc.org/DeveloperInfo/PreReleases

If you've modified any of the server configuration files, then updating
the RPM will cause those files to be backed up with an .rpmsave
extension, so you can restore them if you decide to re-install 2.2.6.

[joa...@verona.se]

** 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

- In Krita the line width is the same, drawing with finger or mouse

- Pen jitter prominent in 2019 is gone, I guess
https://github.com/TurboVNC/turbovnc/issues/198

- Now Xinput 2 is used, im not sure it affects my usecases, but there
are no regressions either

- Drawing remotely is kind of laggy, as compared with drawing
locally. Im interested in seeing what can
be done about this

- I started using alr, and its nice when using emacs for instance,
since i can use low bandwidth, jpeg artifacts dont matter so much
while typing, and its nice that text becomes crisp after a while not
typing
/opt/TurboVNC/bin/tvncconfig -set ALR=5
/opt/TurboVNC/bin/tvncconfig -set ALRAll=true

- vglrun worked nicely for 3d apps, and vglserver_config worked well
to get the environment working(but i had to reboot like 3 times)


--
Joakim Verona
joa...@verona.se

[DRC]

On 9/14/21 2:18 PM, joa...@verona.se 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.

> - 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.)

[joa...@verona.se]

DRC <d...@virtualgl.org> writes:

> On 9/14/21 2:18 PM, joa...@verona.se 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
joa...@verona.se