search

Xpra-org / xpra-html5

HTML5 client for Xpra
Mozilla Public License 2.0
214 stars 57 forks source link

Use "Local Scaling" in the xpra-html5 client just like noVNC without resizing the remote screen in the server #75

Open ehfd opened 3 years ago

ehfd commented 3 years ago

Very related to https://github.com/Xpra-org/xpra-html5/issues/13 and https://github.com/Xpra-org/xpra-html5/issues/4#issuecomment-868275246 @basilgello @totaam

There is a situation where setting a fixed resolution like VNC (remote screen not resized to the client window size) is required in Shadow or Desktop mode, as well as the Windowed mode. In Windows laptops, most laptops on 1920 x 1080 for example have Scale and layout in the Display to 125%. We can see that the resolution resized in xpra-html5 is 1536 x 864, 80% of 1920 x 1080 in width and height. This results in sub-optimal resolution. Other than this, there may be a requirement where something has to be rendered remotely in a higher resolution than the local display resolution. A current pretty ugly workaround is to set zoom settings to 80% in the web browser or set Scale and layout across the whole OS to 100%. Or https://github.com/Xpra-org/xpra-html5/issues/4#issuecomment-868275246. Similar situation in Mac or Linux probably.

In noVNC (https://novnc.com/noVNC/vnc.html), if you see Settings (the gear wheel on the left toolbar) -> Scaling Mode, there are three options. It doesn't fix the Scaling issue automatically, but at least there is one option that allows to downscale the remote screen while keeping the resolution The first is "None", which uses a scroll bar to navigate through the larger remote screen. The second is the "Local Scaling" option. This scales the client window size by just using html5 to fit either the width or height, but doesn't attempt to resize anything remotely. Even if Scale and layout in the Display is set to 125%, it is able to obtain 1920 x 1080 in full screen with this option because the noVNC client scales locally on its own to fit either the width or height of the web page and counteracts the Windows settings. The third option is "Remote Resizing" which is what xpra-html5 does right now.

It would be very trivial if there was an option equivalent to setting a fixed geometry in the xpra server with Desktop mode (just like VNC), and we could toggle the "Local Scaling" option in the floating menu while connected to the remote display. I hope this can be implemented very soon, perhaps by referring to the code from noVNC.

But another question, is xpra-html5 mature enough? I tested pulseaudio and it seems to have a few second lag. Probably related to https://github.com/Xpra-org/xpra-html5/issues/15#issuecomment-765524966. Should I try another solution like TurboVNC + Guacamole with pulseaudio for my use case until xpra-html5 matures?

basilgello commented 3 years ago

Did you try Client Width in HTML5 client, just in case?

ehfd commented 3 years ago

Did you try Client Width in HTML5 client, just in case?

I am using the stable version now, I didn't see that in the client advanced settings... Do I need beta? Plus I can say users need something better than calculating pixels manually...

basilgello commented 3 years ago

Do I need beta?

Yes you need beta :)

And yes, this can be extended as it was the first step to solve my issue immediately

ehfd commented 3 years ago

One additional thing needed is the ability to specify an unresizable fixed resolution in the xpra server option --resize-display, not only setting an initial resolution and making it resizable. And pulseaudio indeed seems at least 3-4 seconds out of sync in xpra-html5 as well...

ehfd commented 3 years ago

Do I need beta?

Yes you need beta :)

And yes, this can be extended as it was the first step to solve my issue immediately

Yes, I got it to work by building the latest xpra-html5 git repository. Screen doesn't look blurred and looks pretty native, but it still changes the height on its own.

One additional thing needed is the ability to specify an unresizable fixed resolution in the xpra server option --resize-display, not only setting an initial resolution and making it resizable.

In xpra-html5, "Client Width should progress to a "Local Scaling" option that automatically downscales the screen to fit either the browser window height or the weight regardless of OS scales should exist. And in xpra server, it should be able to enable a VNC-like option for fixed resolution without remote scaling.

While the h264 and vp encoding is very attractive and can only be implemented with xpra, I should choose Guacamole with TurboVNC for my container to support audio for now, but these things are stuff that can benefit greatly.

totaam commented 3 years ago

One additional thing needed is the ability to specify an unresizable fixed resolution in the xpra server option

No, that's not needed. The server only responds to requests from the client. The client just needs to be taught not to request the server to resize.

And pulseaudio indeed seems at least 3-4 seconds out of sync in xpra-html5 as well...

It's not pulseaudio that's the problem, it's the browser's audio. The solution to that is probably to use a different API: Segmented-Audio over Websockets to HTML5 It currently chooses a 1-second fragment size. The reassembly buffer requires a few segments before it starts. The resulting audio latency is 4 to 5 seconds as a result., This lesson was apparent in the application. Without backpressure monitoring, we could not control latency properly.

basilgello commented 3 years ago

With pulseaudio, audio stream stutters every 4-5 seconds even with gtk3 client…

totaam commented 3 years ago

I am currently unable to test because Fedora 34 moved to pipewire (https://github.com/Xpra-org/xpra/issues/3212), which broke everything. @basilgello what sort of network connection are you on to get this stuttering? (I don't usually get any on LANs)

basilgello commented 3 years ago

Loopback interface :(

totaam commented 3 years ago

Oh, which codec? Does the session info graphs show anything useful? (you can save the graphs by clicking on them) Stuttering is usually seen as underruns or overruns. When it happens repeatedly, that's usually a sign that the gstreamer clock synchronization is going awry.

ehfd commented 3 years ago

I am currently unable to test because Fedora 34 moved to pipewire (https://github.com/Xpra-org/xpra/issues/3212), which broke everything.

Side note: Pipewire is very useful to create a remote desktop system mainly in Wayland systems because it can forward video as well as audio. I am waiting for a drop-in VNC/RDP replacement that accesses the X server or Wayland compositor to be able to do high speed video encoding of the screen, something similar to what Parsec or NVIDIA Gamestream does (it gives a clean and low-latency remote desktop experience that resembles being in front of a physical desktop even when unrelated to gaming) except on html5, and I think Xpra with NVENC looks pretty close to that once the audio lag problem on html5 is solved.