The resize option does not scale, no. It tells the server to change the size of the session. Many servers do no support this (in fact, I think only TigerVNC does).

thanks. yes, what I am looking for is having the remote screen, whatever its size, scaled to fit the client window. Just like an image scales when you shrink/expand a window. Thanks for changing title/.status

I'm not trying to troll this thread, but I wanted to point out that the TurboVNC Server (2.0 and later) also supports the remote desktop resizing feature, which is a useful sanity check if any compatibility problems are suspected.

As far as scaling, our viewers support that, and they can be used with the TigerVNC Server.

@CendioOssman This seems to work perfectly when the server is running on Linux. Is it possible to make this work when a Windows machine is running the server component? Edit: To clarify, I'm primarily asking about resizing remote session to the local window when the server is on windows.

Possibly. But probably only to the fixed resolutions that are already available.

We don't have anyone working on WinVNC though, so it's not really getting much in the way of improvements. You could add an enhancement request though, and maybe put a bounty on it.

This is so needed. When I connect to my home laptop w/ TigerVNC on my MBP, TigerVNC displays each remote pixel as 2x2 (2x zoom) on the MBP, so the screen is hugely zoomed in and the scrollbaring is just painful. (It seems like some sort of "retina" thing, as if it doesn't think my home laptop — which has a HiDPI screen — has a HiDPI screen.)

Agree with the "so needed" comment above. Working from home will be next to impossible since my monitors are smaller than at work. Changing the server resolution only leaves my carefully placed windows half off the screen. Local client scaling would solve this problem.

If I possessed the software skills to do so I would, but I'm a lowly EE whose company IT only supports TigerVNC for all engineering work. So far everything works perfectly, except this one thing.

Have any bounties been offered on this feature? How much would it take to make it happen?

No bounty yet, no. And unfortunately I have no idea what it would take to pique someone's interest. You'll just have to start and see if you get some attention. :)

Note that the bountysource integration is currently broken, so it won't get properly flagged here in github.

The reason I asked what it would take is because I had the crazy idea of seeing if there was any possibility of getting my company to pay for it. Not sure how likely that would even be, but without a price tag on getting it done for sure, I can't really even ask the question.

This is probably a stupid question, but I think there are other VNC clients that already support this feature. Do different open source versions of VNC ever share that kind of code with each other? I think it was mentioned above that TurboVNC supports client scaling. I tried using that with whatever server our IT is running (I'm not sure what it is, but I don't think it's TigerVNC server, and I'm not sure how I find out what it is) and it didn't work. Something about unsupported or incorrect authentication or encryption modes. I also tried TightVNC and RealVNC viewers, similar issues. TigerVNC seems to be the only one that supports whatever form of authentication IT has setup on the server, and is the only one that IT will officially support anyway.

But without client scaling, it's practically unusable for my setup when changing between 2 locations with different resolution capabilities. Any help, guidance, or ideas on how it would be possible to get this feature added would be highly appreciated.

Like DRC's TurboVNC client, the TigerVNC Java client also supports client-side scaling.

So when I disable (uncheck) the option "Resize remote session to the local window" and then change the size of the client window, it does not scale. It crops and gives me scroll bars. If it supported client side scaling I would expect an option to select if that's what is desired, as well as the option to lock the aspect ratio when doing so.

I simply downloaded vncviewer.exe and run that on windows. Maybe I'm not using the Java client you specifically referred to?

That's the native client. The Java client has the options you are expecting and can be downloaded here:

https://bintray.com/tigervnc/stable/download_file?file_path=VncViewer-1.8.0.jar

Then just double click it to run (requires you to have Java 6 or higher installed).

You can also download the latest nightly build from the link on the tigervnc.org home page. There's some fixes in the latest versions related to cursors on Windows.

Ok, this may sound weird, but I think I love you. :P

I absolutely can't thank you enough for pointing me in the right direction. The Java client works perfectly and does exactly what I need.

You may have saved my job at this company... thanks again!!!!!

Happy to help, sorry that I didn't see this issue sooner!

No worries, just glad you saw it! I'm already in the process of compiling directions to everyone in my group and I'm going to tell IT about it as well. Hopefully the native client will have the same feature one day, but I'm happy for now.

Had to do a little searching on how to pin a jar to the taskbar and make it's icon the TigerVNC icon, but was a piece of cake to do that.

Can't say thanks enough times... :)

You might want to look into Java WebStart, it's a great way to deploy jar files so that they look & feel like native apps. More importantly, it allows updates to be pushed out remotely.

I'll certainly mention it to IT when I tell them about the Java client. I'm just a lowly user that refused to deal with something that was annoying me. :P

I knew I got a little too happy a little too soon and jinxed myself.

The Java client is not handling certain key combinations correctly. I use xemacs extensively and can't seem to do combinations of Shift, Ctrl, and Alt. For instance, Shift-Ctrl-Alt L is used to toggle between buffers. After switch to the Java client, xemacs only seems to see Shift L. This is actually a more serious issue than I started with... bummer.

I found a somewhat old issue about this that seemed to have to do with FLTK being out of date. Don't think that applies to the Java client though...

Help? New issue?

I'll have to look and see if I can reproduce this, but yes this should be considered a separate issue.

We are quite interested in scaling with the native client, mainly to be able to reduce VNC traffic. We would be willing to fund this at least partially. The Java client is no option for us.

I have already looked into the code for a while, but the dependencies between the layers seem too complicated for a quick solution. A fixed scaling factor through a parameter, e.g. 2x2, would be great - then resizing could still work, just that the output is always scaled.

bump

I fully agree that a constant scaling factor selected with the command line parameter (e.g. --scale 3x3) would be perfect. I need to access the same VNC session both from the old display with 1280x1024 resolution end from the new 4k display. Without that feature it is really a nightmare.

I have just found "gvncviewer" available for my Debian system. It supports client-side scaling.

Is it so hard to implement a scaling feature all these years? Absolutley disappointing!

Is it so hard to implement a scaling feature all these years? Absolutley disappointing!

Just install Remmina with vnc plugin. apt install remmina-plugin-vnc

It scales client locally, and works well.

remmina -c vnc://host:port

but with remina it's not gpu accelerated. tigervnc <-> tigervnc server is much faster.
1.13.1 and STILL no local resize option!!!

If both server and client are TigerVNC, then the session should be able to resize dynamically to the client, rather than scaling. Is that not working for you?

Absolutely not right for me. I also have x11vnc + real x11 server running as i need DRI3 sometimes for games (vulkan). (Or tell me if i can make DRM3 work in vncserver.) Target screen is 1080p and my monitor is 1080p. I dont want to run fullscreen so i need a window mode with scaled image.

I also don't want to run full screen, I use wayvnc, so agree client scaling please.

i wonder what is packet in the 34mb large exe file as it is not even capable of local scaling. (tightvnc only has 1mb and supports scaling!)

In my case I connect to the same 1080p VNC session from a 1080p laptop, and from a 4K screen desktop. While it is perfect as-is on the laptop, connecting from the desktop it is more comfortable to view it at 1.5x scaling. Thanks

A long while ago I implemented scaling with pixel doubling either only horizontally or both horizontally and vertically in our own encoder. We were all quite unhappy with the result - the image looks blurred at best. Based on this, I would not recommend this kind of scaling. We are no longer interested in the scaling feature.
For bandwidth reduction, we use JPEG quality 8 when needed, or use H264 (again with our own encoder). JPEG XL looks very promising, quality as high as JPEG with much less bandwidth, but CPU usage is much too high. I am still working on that. H264 works quite well, but still needs much more CPU than JPEG and the image quality is not optimal for desktop use. To satisfy the CPU needs of H264 and JPEG XL we use multi threaded encoding, which has its own bit of overhead for synchronization.

Scaling is supposed to be available in Fltk v1.4.0

I'm not familiar with FLTK at all. Which function do we care about, is it scale?
That one seems to be available since FLTK 1.3.4, which corresponds to e.g. Ubuntu 18.04.
But even in Ubuntu 22.04 I don't get scaled contents when I resize the client VNC window (using e.g. x11vnc as the server).

Are we still waiting for more upstream FLTK changes before this can be implemented?
I'm not looking for server-side resizing or encoding. I only care about the image to fit the window when I resize the VNC client...

We are not waiting for FLTK for this one, no. That's for high DPI support.

What's needed here is that someone looks at the current rendering pipeline and figures out how to efficiently add scaling to that. Basically, the "Surface" classes in vncviewer.

issue is 7 years old and still not solved?

nope

Hey, there is a draft pull request for x11 implementation

I came across libswscale just a few days ago and from a cursory look it seems like it would be a minimally invasive way to scale the native pixel buffers. The nice thing there would be that it should be cross-platform. I have no idea what the performance is like but IMO scaling should be expected to come at a cost.

I came across libswscale just a few days ago and from a cursory look it seems like it would be a minimally invasive way to scale the native pixel buffers. The nice thing there would be that it should be cross-platform. I have no idea what the performance is like but IMO scaling should be expected to come at a cost.

As I understood correctly, there is used low level rendering API for each platform. If we would use any cross-platform library for rendering here, we could have scaling and zooming a long time ago.

I was looking at this function which could be used to create a scaled copy of the pixel buffer. I don't see why anything should need to change with regards to rendering because the changes you've already made in the PR would setup the surfaces to correspond to the size of the scaled buffer. This is basically the same thing that I did to add scaling to the Java viewer.

ffmpeg is problematic since distros often exclude it for patent reasons. libswscale is likely fine in that regard, but it might still be excluded since it is part of ffmpeg. We'll need to check that it is widely available before we rely on it.

I assume it is also a pure software implementation? We should try to leverage hardware acceleration first, so the scaling doesn't become a big bottleneck.

how many years still to come until local scaling is supported. why is it so hard to do?

What is the roadmap for implementing this feature?
Is it OK if it would be implemented for X11 only?

How to integrate this feature with server side resize?

1. It can be an option to choice (server side resize or client size resize)
2. Client size resize works only if server side resize don't
   In my opinion option 1 is better as it gives choice to user and easier to implement.

What is the roadmap for implementing this feature? Is it OK if it would be implemented for X11 only?

Not really. We want to maintain feature parity between our different platforms.

How to integrate this feature with server side resize?

1. It can be an option to choice (server side resize or client size resize)

2. Client size resize works only if server side resize don't
   In my opinion option 1 is better as it gives choice to user and easier to implement.

We should avoid bothering the user with settings if we can. So I would prefer we try with everything always enabled and see what feedback we get.

I was directed here by a lot of reviews hailing this as one of the best viewers with a huge community of support.

Setup was easy enough after I figured out which of the practically indistinguishable binaries was the installed viewer. I connected in window mode, but the resolution on the Mac is significantly larger than my Windows machine. There are some universally understood standards and one is that setting fullscreen would scale to the size of machine.

Instead, I had to fight my way back out of the app to discover we are 7 years info this being a known flaw that has been explained by "not bothering the user with settings." Which do you think is more frustrating? An extra checkbox or fighting your way out of the app so you could uninstall it?

... I think you need to reevaluate your priorities on this one.

The reason that this still isn't available in TigerVNC is not that we want to avoid additional settings.