OK, a first attempt at this for GTK+ 3.0 only is in the "feature-135-arbitrary-scaling" branch. The basic principle is to use the scalers as we currently do scale up by integer amounts, and then to hand off to Cairo to do "the last mile".
Seems to work pretty well to me, other than some glitches which occur when scaling the window as you move from 1.99x (1x scaler, Cairo providing 1.99x scaling) to 2.00x (2x scaler, Cairo scaling not being used). However, for the first time you can now maximize the Fuse window without really bad stuff happening :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just committed a change which prevents the forced resize of the window on scaler change if the scaler change was itself caused by a window resize. This led to a "fight" between the window manager wanting the window to be one size and Fuse trying to force it to another which caused some of the glitches when resizing the window.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With Xfwm there are some quirks when dragging the corner of the window, also with mutter. I don't see any reason to keep the aspect geometry and the window resizes more naturally if the aspect hint is disabled. Patch attached.
It would be nice to keep the scaler "family" when resizing, e.g., PAL TV <-> PAL TV 2x <-> PAL TV 3x
If "Double" scaler is selected and the window is resized to 2.1x size, there isn't an easy way to return to 2x size, i.e, change to "Normal" scaler and then again to "Double" scaler.
Sergio: your comment on the wiki page says that this is unusable on Wayland and you have an idea to test - I assume this is still the case? (Sorry, not able to test Wayland at the moment as I'm running NVIDIA drivers for various reasons...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Wayland the spectrum frame is always bigger than Fuse window, no matter how big the window resizes (see attachment). I think this should be fixed before merging.
Summarizing, to set the desired size of the drawing area we need to set the exact size of the window. That includes the window shadow on Wayland and other decorations [1]. The idea I'm trying is measuring the size of the drawing area and the window when they are realized (before window is visible) to calculate the space needed for the window and do any adjustments.
That works well when manually resizing. Currently I'm stuck when setting the size via command line or restoring the settings file. Events at Fuse initialisation are bit convoluted, i.e., happen multiple times and not in the best order. IMO settings (and filter size) should be available before UI initialisation. I'll retake this feature and share the code for reviewing.
BTW, I run a Fedora VM with VirtualBox to test wayland.
I've been testing the feature-135-arbitrary-scaling branch, with Wayland (gnome-shell 3.38.5) there's a lot of artifacts if I resize the window manually. With X11 (same desktop session but using XWayland) everything seems to work fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, a first attempt at this for GTK+ 3.0 only is in the "feature-135-arbitrary-scaling" branch. The basic principle is to use the scalers as we currently do scale up by integer amounts, and then to hand off to Cairo to do "the last mile".
Seems to work pretty well to me, other than some glitches which occur when scaling the window as you move from 1.99x (1x scaler, Cairo providing 1.99x scaling) to 2.00x (2x scaler, Cairo scaling not being used). However, for the first time you can now maximize the Fuse window without really bad stuff happening :-)
OK, branch updated and we now have true full screen Fuse (in GTK+ 3 land, anyway). Hit F11 for goodness.
There are quite a lot of glitches here with regards to window resizing / restoring after fullscreen mode but it basically works.
This is looking really great!
I've just committed a change which prevents the forced resize of the window on scaler change if the scaler change was itself caused by a window resize. This led to a "fight" between the window manager wanting the window to be one size and Fuse trying to force it to another which caused some of the glitches when resizing the window.
And a wiki page now created to evaluate whether this code is ready to go into a release... https://sourceforge.net/p/fuse-emulator/wiki/Arbitrary%20scaling/
With Xfwm there are some quirks when dragging the corner of the window, also with mutter. I don't see any reason to keep the aspect geometry and the window resizes more naturally if the aspect hint is disabled. Patch attached.
It would be nice to keep the scaler "family" when resizing, e.g., PAL TV <-> PAL TV 2x <-> PAL TV 3x
If "Double" scaler is selected and the window is resized to 2.1x size, there isn't an easy way to return to 2x size, i.e, change to "Normal" scaler and then again to "Double" scaler.
Sergio: your comment on the wiki page says that this is unusable on Wayland and you have an idea to test - I assume this is still the case? (Sorry, not able to test Wayland at the moment as I'm running NVIDIA drivers for various reasons...)
On Wayland the spectrum frame is always bigger than Fuse window, no matter how big the window resizes (see attachment). I think this should be fixed before merging.
Summarizing, to set the desired size of the drawing area we need to set the exact size of the window. That includes the window shadow on Wayland and other decorations [1]. The idea I'm trying is measuring the size of the drawing area and the window when they are realized (before window is visible) to calculate the space needed for the window and do any adjustments.
That works well when manually resizing. Currently I'm stuck when setting the size via command line or restoring the settings file. Events at Fuse initialisation are bit convoluted, i.e., happen multiple times and not in the best order. IMO settings (and filter size) should be available before UI initialisation. I'll retake this feature and share the code for reviewing.
BTW, I run a Fedora VM with VirtualBox to test wayland.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1269437
I've got a fix to the Wayland issues. It's not the refactoring I'd like to see, but works. Any tests on wayland and x11 backends are welcome.
I've commited these changes. Tested on x11, wayland and windows backends.
I've been testing the
feature-135-arbitrary-scalingbranch, with Wayland (gnome-shell 3.38.5) there's a lot of artifacts if I resize the window manually. With X11 (same desktop session but using XWayland) everything seems to work fine.