Comment 1 Pierre Ossman 2025-02-05 10:15:37 CET

We could also consider making the interactive resize more responsive, as we haven't seen many issues with resizing.

We likely still need some limiting, though. At the very least, making sure we don't request resizes faster than the server can respond to them.

Comment 2 Pierre Ossman 2025-02-05 14:15:39 CET

Turns out that we could resolve this in a way more general way, that gave us both responsiveness and some protection against spamming the server with resize requests. And that way is rate limiting.

The first resize, no matter the reason, goes to the server immediately. The next resize gets delayed if it happens too quickly.

This neatly solves the issue of in and out of full screen, as well as maximize and un-maximize, as those are just single resize events.

For interactively resizing the window, we can now control exactly how responsive we want that to be.

I settled on once ever 100 ms. It is almost instantaneous, whilst at the same time a decent amount of time for the desktop and applications to react. 

I also added a rate limiter that we won't send another resize request until we've got a response for the previous one.

Comment 3 Pierre Ossman 2025-02-05 14:24:15 CET

Upstream issue:

https://github.com/TigerVNC/tigervnc/issues/1763

And pull request:

https://github.com/TigerVNC/tigervnc/pull/1904

Comment 5 Pierre Ossman 2025-02-06 14:31:28 CET

Upstream noVNC pull request:

https://github.com/novnc/noVNC/pull/1932

Comment 8 Pierre Ossman 2025-02-07 11:03:37 CET

Odd. The interactive resize doesn't work on Windows or macOS. But it's not the OS, as I can see the FLTK scroll bars reacting to the change. So it seems it is FLTK that is not propagating things to us for some reason.

Other than that, it works fine. Tested the native client on macOS 15, Fedora 41 and Windows 11. Also tested Web Access in Safari on macOS, Firefox on Fedora, and Chrome on Windows.

Comment 9 Pierre Ossman 2025-02-07 11:43:23 CET

Turns out that this is a more general bug, so I've filed bug 8513.

Not much we can do here until that is resolved.

Comment 10 Pierre Ossman 2025-02-08 15:05:44 CET

One case was overlooked, and that is when starting in full screen. We have a timeout there in case the window manager decides to ignore our full screen request.

Comment 12 Adam Halim 2025-02-10 16:21:16 CET

Tested client 3801 and server 3911 on RHEL 9.

Tested the native client on:
============================

* Fedora 40 GNOME
  - Very responsive when resizing the window.
  - Fullscreen (un)maximize instant.
  - Tested with GNOME & Xfce on the server.

* Windows 10
  - Resizing is not interactive, and the remote is only resized after
    releasing the window (bug 8513).
  - Fullscreen and (un)maximize instant.
  - Tested with GNOME on the server.

* macOS 15
  - Resizing is not interactive, and the remote is only resized after
    releasing the window (bug 8513).
  - When maximizing the window, the resize happens after the animation.
  - Fullscreen instant.
  - Tested with GNOME on the server.


Tested Web Access on:
=====================

* Fedora 40
  ✅ Firefox
  ✅ Chromium
  ✅ Edge

* Windows 10
  ✅ Firefox
  ✅ Chrome
  ✅ Edge

* macOS 15
  ✅ Chrome
  ✅ Edge
    - On Chrome and Edge, when double-clicking on the window title bar to 
      maximize/minimize the window, the remote session is resized constantly
      during the animation. The performance (on our x86 mac) was a bit 
      sluggish during the animation, but I think it's still OK. This does not 
      happen when clicking on the native fullscreen button.
  ✅ Firefox
  ✅ Safari
  

Starting a session with fullscreen enabled:
===========================================

✅ Fedora  40 GNOME
✅ Windows 10
✅ macOS   15

Comment 13 Adam Halim 2025-02-10 17:10:35 CET

In general, I think the experience is greatly improved with this fix across all platforms.

> MUST:
>  ✅ Session should resize without delay when maximizing
> 
>  ✅ Session should resize without delay when entering full screen
Indeed, the session is resized without any delay when entering full screen on all platforms. The same is true for maximize, except on macOS where there is a delay until after the maximize animation is finished. The issue might be related to bug 8513. Given the circumstances, I think this criterion can be considered fulfilled.
> SHOULD:
> 
>  ✅ Session should resize without delay when un-maximizing
Same as previously mentioned, un-maximizing on macOS occurs after the animation has finished. On the other platforms, this works fine.
>  ✅ Session should resize without delay when leaving full screen
Indeed, this happens on all platforms.
>  ❌ The session should resize responsively when resizing the client window
This criterion was not fulfilled and has been moved out to bug 8513.

I've looked through the upstream commits & release notes and think they look good.

Closing.