HQ filter broken when applied as a global setting

[tsoliman]

The HQ filter seems to be slightly broken for me and for sluicebox when running a hires game (e.g. COMI or KQ7) in the latest master (e6db9ded56)

I am using a 2015 macbook pro 15" (retina display)

Steps to reproduce:

• Launch ScummVM using a HiDPI display
• Switch to SDL HQ3X (you now have to explicitly pick SDL Surface and then pick HQ and 3x as a factor)
• Launch a hires game
• Note the window being abnormaly huge
• Press Ctrl-F5
• Note the GMM being tiny

This doesn't occur in older master (3b47e561552) so it is a recent regression.

[sev-]

Testing showed that it did not get broken, it behaves like in pre-HiDPI. We are not applying GUI scaling in non-OpenGL because SDL reports 1:1 pixel ratio, e.g. non-retina.

[tsoliman]

I attached screenshots from the old commit mentioned to show that this used to work fine in that commit.

[tsoliman]

I also attached screenshots from the latest master (e6db9ded56) to show what it now looks like. Note that this "giant window" effect happens in any HQ filter mode (2x or 3x) but not in normal 3x scaling

[criezy]

This is not really a regression in that the current behaviour matches the behaviour in the last release.

The work on HiDPI has added the ability to scale the GUI. This was meant to be used primarily for HiDPI displays, but there were several intermediate steps with different ways to scale the GUI that had unintended consequences. What you see in your screenshots is one of those.

I suspect that changes that "breaks" that (and restores the 2.2.0 behaviour) is ad31dfc8d5. Before that commit the GUI was clipped to a resolution of 960x720 max, with a scaling applied to match the window size if greater than that. This was not optimal in the launcher where having a higher resolution for the GUI can be welcome, and it also had a few others quirks and unexpected behaviour.

The good news is that all this work to support HiDPI does mean that we can now scale the GUI, so it might not be too complicated to improve on the current behaviour. But I see this has an enhancement rather than bug fix, and I am not sure I would say the current behaviour is broken.

We could for example try to scale the GUI according to the original game resolution when displaying GUI dialogs in games. But that might not work that well for 320x200 games for example.

Note that this "giant window" effect happens in any HQ filter mode (2x or 3x) but not in normal 3x scaling

I am confused by this statement. Could you clarify what this means?
I just made a series of tests on macOS with current master and the behaviour is the same for me for both Normal 3x and Hq 3x (and I also checked it is consistent with the way it behaved in the 2.2.0 release). I also do not see any reason why HQ scalers would behave differently from Normal scalers.

[tsoliman]

The behavior is not the same for me in normal and hq.
HQ results in a giant window whereas normal doesn't.

sluicebox saw this as well.

[tsoliman]

I just checked the latest release 2.2.0 and it behaves like the old commit (working fine)

[sev-]

Raising priority as the release blocker.

[criezy]

Let's put aside the GUI menu size for now and focus on the window size.

I am not sure what window being abnormaly huge means, but I did some additional tests and I am getting the expected window size with both Normal and HQ scalers.

You can run scummvm with -d 3 to get output on the window size.

On a Retina laptop I cannot test 3x scalers as the screen is too small, but with 2x scalers and COMI I get the following:

Normal 2x: Setting 1280 x 960 -> 1280 x 960 -- 1
HQ 2x: Setting 1280 x 960 -> 1280 x 960 -- 1

That is the expected size, and it matches what I get with ScummVM 2.2.0.

Note: with Surface SDL mode, since HiDPI is not enabled, we are running in compatibility mode and the OS applies a 2x scaler on its own. On the ScummVM side we see things as if the screen had half the DPI that it really has. So the window is actually 2560x1920.

On my non-retina iMac, I can test the 3x scalers and I also get the expected result:

Normal 3x: Setting 1920 x 1440 -> 1920 x 1440 -- 1
HQ 3x: Setting 1920 x 1440 -> 1920 x 1440 -- 1

In all cases I am getting the expected window size, and it matches the size I have with ScummVM 2.2.0.

[criezy]

I think I finally understand what this bug report is about, and it is not related to HiDPI.

The issue is when setting the scalers in the global option, and not overriding them for the game. In such a case with ScummVM 2.2 we do not apply the scaler to 640x480 games (or bigger) and display them at their original resolution (e.g. 640x480).

With current master this is still the behaviour with the Normal scales, but not with the other scalers. For those the scalers gets applied to the game as well, so instead of 640x480, we get 1280x960 or 1920x1440.

I suspect this is a regression either from the scaler plugin pull request or from the pull request to split the graphics modes and scalers into two separate popups.
Indeed the HQ scalers do not have a 1x mode, which might be why it sticks with the 2x or 3x for the game as well.
​https://github.com/scummvm/scummvm/pull/2358
​https://github.com/scummvm/scummvm/pull/2853

[criezy]

I have now verified with a bisection that this is a regression from PR 2853 GUI: Add improved scaler selection to the Options dialog

The exact commit that causes the regression is the first one from that pull request:

commit 0e6b9c2bb6738dcf15d0dcc534aedacf8de78c1b
Author: Cameron Cawley <ccawley2011@gmail.com>
Date:   Tue Jan 5 22:54:53 2021 +0000

    SDL: Begin refactoring the API for selecting scalers

[criezy]

Fixed in 478fbbbe9b