MacOS test results

Generally there is improvement; the original reported issue is gone! 🎉 There's also less flicker and the windowed/fullscreen switching it a bit faster in the OpenGL modes. In texture modes there's no difference as the flicker and slowness was only happening in the OpenGL modes.

Now, I noticed a couple of issues. I haven't cross-checked these against main to see whether they're regressions or pre-existing stuff. Anyway, here we go.

Will test on Windows tomorrow.

Case 1

[sdl]
fullscreen = off
output = texture | opengl
windowresolution = 960x720

Issue 1

1. Resize & move window
2. Switch to fullscreen & back
3. Position is retained, but window size is not
4. Resize & move window again
5. Switch to fullscreen & back
6. Both position & size are retained from the 2nd time onwards

Window position is retained doing the same test, just not the size.

Issue 2

1. Switch to fullscreen & back
2. Resize window to desktop width only horizontally
3. Switch to fullscreen & back
4. Note that window jumped back to its default size
5. Resize window to desktop width only horizontally
6. Switch to fullscreen & back
7. Window size is retained from the 2nd time onwards

Case 2

[sdl]
fullscreen = on | off
output = openglpp
windowresolution = 960x720

Window position is always retained, resized window size is never retained.

Case 3

[sdl]
fullscreen = on
output = openglpp
windowresolution = 960x720

1. Switch to windowed mode
2. Note the window size is correct but the scaling factor is wrong; the contents of the window is way too small and there's a huge black border around it
3. Switch to fullscreen & back
4. Now the scaling factor is correct
5. After this, we're back to the problem from Case 2 -- the window position is always retained, the resized window size is never retained.

Case 4

[sdl]
fullscreen = off
output = openglpp
windowresolution = 960x720

Same as Case 2.

@johnnovak , thanks for the repro details. I think all should be addressed in the new commits - except I'm still not sure about:

the window size is correct but the scaling factor is wrong; the contents of the window is way too small and there's a huge black border around it

output = openglpp
windowresolution = 960x720

This is what I'm seeing (matching your description); I think it's correct given for a 960x720 window, pixel perfect cannot double the 640x400 text-mode up to the desired 1280+ width (with only a 960-wide window):

DISPLAY: Text 640x400 16 color (mode 03h) at 70.087 Hz VFR,
         scaled to 640x400 with 1 pixel aspect ratio

But if I give it more room:

output = openglpp
windowresolution = 1280x960

DISPLAY: Text 640x400 16 color (mode 03h) at 70.087 Hz VFR,
         scaled to 1280x800 with 1 pixel aspect ratio

That's on Linux, but it's similar for me on macOS because I have a normal DPI screen.

More on case 3:

@johnnovak, @GranMinigun helped look over the PR.

> <GranMinigun> 960 * 200% = 1920; 1920 / 640 = 3...

Captured some footage from the mac to re-check it using the current PR, and we both think (the updated commits) are now doing the right, but that's given my non-hi-DPI screen.

Video:
https://kcgen.duckdns.org/Screen%20Recording%202023-04-03%20at%202.29.00%20PM.mov

Curious what you see on your side w/ the latest commits.

I did some tests using 1280x960 window resolution on my Gentoo Linux system - didn't notice any issues, but I haven't checked whether the pixel-perfect scaling modes really sets proper scaling.

I can't test right now @kcgen , but if you do the test in Case as I described, the scaling is different between step 2 and 4. Both cannot be right.

The issue is not present with texturepp. So at the very least we are inconsistent.

What you wrote about the pixelperfect mode is logical, but I think there is another thing at play, namely thst we are forcing 640x480 min window size (I think).

This is another issue I did not flag because it seems unrelated but might be easy to fix. You can resize the window to say 100x100, and then do the fullscreen switch, then back to windowed. The window size jumps back to 640x480, and this defaulting to 640x480 min size screws up the pixelperfect stuff.

In fact, what I flagged as issue is the correct pp behaviour, you are right. Meaning everything else that I did not flag about it is wrong :)

I think the window min size should be perhaps set to 640x480 so the user cannot set it to a smaller size, or remove this altogether. I think I would keep it, but disallow the user from resizing the window below the min dimension of 640x480.

Thanks for the checks @FeralChild64. A simple way to check PP is to do a dragging resize. As the window grows, pixel-perfect will "step" the image size up in a stair-case manner (and pretty easy to visually see the multiplier in effect).

Thanks for the quick feedback @johnnovak; no rush on the ticket (want you kicking the tires on the latest revision so you can re-assess).

As for the minimum window size - yes; I'll check if SDL has some bounds we can give it, so it manages those for us.

(context: some of the functions calls this PR removes were used to "fight" with SDL by trying to manage the window size; and want to keep avoiding that approach).

This is going to get better too: @GranMinigun mentioned - "I think I'll be dropping window sizes from sdl struct in the future, as SDL itself tracks both window size and fullscreen display".

As for the minimum window size - yes; I'll check if SDL has some bounds we can give it, so it manages those for us.

This one should do the trick:
https://wiki.libsdl.org/SDL2/SDL_SetWindowMinimumSize

Care needs to be taken that it works with "logical pixels" on hiDPI screens in the expected way.

For the record, I'm a GLFW user myself, and GLFW has a similar function that just works (at least on Windows and macOS, I can't test on Linux):
https://www.glfw.org/docs/3.3/group__window.html#gac314fa6cec7d2d307be9963e2709cc90

(context: some of the functions calls this PR removes were used to "fight" with SDL by trying to manage the window size; and want to keep avoiding that approach).

This is going to get better too: @GranMinigun mentioned - "I think I'll be dropping window sizes from sdl struct in the future, as SDL itself tracks both window size and fullscreen display".

That's a very good idea to remove it; maintaining "shadow dimensions" ourselves is asking for trouble (talking from experience with GFLW). You can make it work, kinda, but it easily breaks on different OSes, OS versions, etc.

Thanks for the quick feedback @johnnovak; no rush on the ticket (want you kicking the tires on the latest revision so you can re-assess).

That's fine. I'll wait until you put in the minimum window size stuff, should be easy enough and it will spare me another time consuming full testing cycle. Just let me know when that's in and I'll retest everything on Windows & macOS!

I'll wait until you put in the minimum window size stuff, should be easy enough and it will spare me another time consuming full testing cycle.

👍 all set now. Tested as much as I could on my side; minimum bounds are being respected.

New results. There are improvements, but there are also regressions. I'll only test Windows once everything is perfect on macOS. OpenGL seems to be generally more difficult to get right, the texture backend is almost perfect.

Haven't listed all possible permutations explicitly because it's overwhelming; just read the descriptions carefully as I've included comments about the permutations/variations. That should be enough to fix the issues because 2-3 issues seem to affect all various combos.

macOS

Issue 1

fullscreen = off
output = opengl
windowresolution = 960x720

1. Resize window only horizontally so there's black bars on the two sides.
2. Switch to fullscreen and then back.
3. The window size & position are retained, but the content is stretched to the window! Moving or resizing the window "snaps" it back to the correct aspect ratio.

Same thing happens with output = openglpp; the correct pixel-perfect ratio "snaps" in place only after moving the window or resizing it after exiting fullscreen.

Does not happen with output = texture.

Issue 2

fullscreen = off
output = opengl
windowresolution = 640x480

1. The fullscreen image at start is much larger than it should be.
2. When switching to windowed mode, the the correct 640x480 size is displayed.

Make sure to view the images at "actual pixels" magnification to appreciate the difference.

The issue is the same when fullscreen = on is used; the fullscreen and windowed image sizes are different.

Same issue happens with output = texture too.

Issue 3

[sdl]
fullscreen = off
output = openglpp
windowresolution = 1500x720

Content gets stretched to the window (1st image), then "snaps" to the correct size after moving or resizing the window slightly (2nd image).

Same thing when using fullscreen = on and exiting fullscreen mode.

texturepp works fine.

Thanks for the second round, @johnnovak.

The new window-size-minimum wasn't in lock-step with the minimum content size (leading the the window being able to "cover" the content when resized down). So the next round of updates bring them into lock-step.

Another change is that it moves the "point of change" into a single function, so extra book-keeping isn't needed at every possible change point (suggest reviewing the new commits one-by-one).

Also, I noticed that the these new minimum bounds were scaled up by the DPI factor - leading to a pretty huge window (and yes, with the window size now guanrateed no-smaller-than the minimum, I was blocked from manually dragging the window smaller - with a big DPI value, this felt very overbearing as it forced quite a huge window on me).

So I relaxed the minimum size boundaries by dividing out the DPI's influence, which allows a more generous smaller window - of course, not too small as to risk the user shrinking it away to a pin-point, but small enough that it can be put in the corner of their desktop if they're listening to music or something like that.

Hopefully third try does the trick!

Great progress @kcgen , it's almost there now! 🎉 All previous issues are gone on macOS and everything works as expected, except for a single case.

I'll start Windows testing once this works too.

fullscreen = off
output = opengl | openglpp
windowresolution = 1500x720

The image appears fitted to the window, ignoring the correct aspect ratio. Moving/resizing and switches to fullscreen & back fixes it.

All previous issues are gone on macOS and everything works as expected, except for a single case.

Repro'd and got it. Confirmed all tests are working OK on the Linux side. Hopefully not much left w/ Windows!

Repro'd and got it. Confirmed all tests are working OK on the Linux side. Hopefully not much left w/ Windows!

Good news, it seems that Windows is working fine! See results below. Tested on all 8 different settings:

Fullscreen Pixel Perfect:

Grabbed this build from actions to test!

Works 100% correctly on macOS now @kcgen, great job! 🎉 Will test on Win10 later today.

@ThomasEricB's confirmed all 8 permutations are running good on Windows; will merge as this is a good baseline (Not meaning cut your follow up testing short, @johnnovak !) -- teamwork in action. Thanks guys.

@ThomasEricB's confirmed all 8 permutations are running good on Windows; will merge as this is a good baseline (Not meaning cut your follow up testing short, @johnnovak !) -- teamwork in action. Thanks guys.

I actually even went beyond and tested it swapping between texture_renderer = direct3d11 | opengl | software . Everything seemed normal on BLOOD.

Everything is fine on Windows 10 on my end too @kcgen 🎉