Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ehfd opened this issue Jul 19, 2021 · 11 comments

Comments

@ehfd
Copy link

ehfd commented Jul 19, 2021

Very related to #13 and #4 (comment)
@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 #4 (comment). 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 #15 (comment). Should I try another solution like TurboVNC + Guacamole with pulseaudio for my use case until xpra-html5 matures?

@basilgello
Copy link
Contributor

basilgello commented Jul 19, 2021 via email

@ehfd
Copy link
Author

ehfd commented Jul 19, 2021

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
Copy link
Contributor

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
Copy link
Author

ehfd commented Jul 20, 2021

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
Copy link
Author

ehfd commented Jul 20, 2021

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
Copy link
Collaborator

totaam commented Jul 21, 2021

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
Copy link
Contributor

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

@totaam
Copy link
Collaborator

totaam commented Jul 26, 2021

I am currently unable to test because Fedora 34 moved to pipewire (Xpra-org/xpra#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
Copy link
Contributor

basilgello commented Jul 26, 2021 via email

@totaam
Copy link
Collaborator

totaam commented Jul 26, 2021

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
Copy link
Author

ehfd commented Jul 28, 2021

I am currently unable to test because Fedora 34 moved to pipewire (Xpra-org/xpra#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants