Correctly resizing window on HD monitor?

[bridgs]

Hello y'all! I'm working on a game and noticed a weird resizing issue. Would love some help!

When I run a resizable game, drag the game window to my HD monitor, and resize it there, the game fails to resize correctly and doesn't fill the window. I opened a bug ticket which includes more precise reproduction steps + tech specs: https://bitbucket.org/rude/love/issues/ ... resizes-on

If anyone's run into this before and knows of any stopgap solutions, I'd be super appreciative! I assume it's related to a mismatch in resolution/DPI between my monitor and my laptop. I searched the forums and tried t.window.highdpi = true but that didn't seem to help.

Thanks!

[Sasha264]

Hello & welcome!

The bug is not reproduced on my 4k config on Windows with different DPI settings.
Maybe it's only MacOS feature...
It will be interesting to look at the window resolution, obtained by love in this case. Can you add this code:

Code: Select all

  local w, h = love.graphics.getDimensions()
  love.graphics.print(("window %d x %d"):format(w, h), 4, 10)

  local _, _, flags = love.window.getMode()
  local width, height = love.window.getDesktopDimensions(flags.display)
  love.graphics.print(("display %d: %d x %d"):format(flags.display, width, height), 4, 30)

in the bottom of the love.draw() function and look at the printed dimensions after this bug occures? On the different monitors?

I've got something like this https://monosnap.com/direct/cjfbznW9IlX ... RtEyHDzpgN

[bridgs]

Initially:
window 500 x 500
display 1 1680 x 1050

After resizing successfully on my laptop monitor:
window 726 x 500
display 1 1680 x 1050

After failing to render properly after resizing on my external monitor:
window 679 x 500
display 2 1920 x 1080

[bridgs]

Ah, and the monosnap you shared looks to be rendered correctly! Here's what it looks like when I resize the window on my external HD monitor: http://www.giphy.com/gifs/cmgGlbgcUR7zW2Di9x

Not only does it not properly render the game in the yellow area, but resizing vertically also inappropriately offsets the rendered area vertically.

[Sasha264]

Hm.. this resolutions seems ok.
Another guess: what if you change window not by mouse, but from the code? For example with this code, added to the buttom of the main.lua file?

Code: Select all

function love.keypressed(key)
  if key == "5" then
    love.window.setMode(500, 500)
  elseif key == "9" then
    love.window.setMode(900, 500)
  elseif key == "0" then
    love.window.setMode(1200, 500)
  end
end

So, it must change the window when you press 5, 9 or 0 keyboard buttons. Will the bug reproduce?

[Sasha264]

Wow!! The gif you shared looks really weird
I recommend to add it in your bitbucket ticket, because it perfectly describes the behavior.

[bridgs]

Calls to setMode will transfer the LÖVE window back to my laptop screen, which is my primary monitor. And actually, if I swap it such that my HD monitor is my primary monitor, then LÖVE resizes just fine on my HD monitor but has the same resize failure when resizing it on my laptop. So I guess it's just that whichever screen is "secondary" will be the one where the resize fails.

[Sasha264]

Ok, let's save and set window position and display index with that:

Code: Select all

function love.keypressed(key)
  local x, y, display = love.window.getPosition()

  if key == "5" then
    love.window.updateMode(500, 500, { x = x, y = y, display = display })
  elseif key == "9" then
    love.window.updateMode(900, 500, { x = x, y = y, display = display })
  elseif key == "0" then
    love.window.updateMode(1200, 500, { x = x, y = y, display = display })
  end
end

And I also replaced setMode with updateMode. This shouldn't make a difference here, but looks nicer.

Generally I am sure that this behaviour is a bug and must be fixed.
But at the moment maybe there is a workaround if:

1. setMode / updateMode can resize window corectly on your secondary monitor
2. and you can obtain correct window size with love.graphics.getDimensions()

Than you can manually monitor when window changes and after that invoke setMode / updateMode to resize it again correct way.

[bridgs]

Well this is interesting! If I add this to my code:

Code: Select all

function love.keypressed(key)
  local width, height = love.window.getMode()
  love.window.updateMode(width, height)
end

Then what happens is I can drag the LÖVE window to any screen/monitor, and if I then press a key it'll become "attuned" to that screen (for lack of a better word). And from then on the window will resize correctly on that screen. If I then drag the window to any other screen/monitor, it'll fail to resize properly until it's "attuned" to that screen by pressing another key while it's on that screen.

So... weird! I might be able to leverage this to craft a workaround for my purposes. But if this an issue that's solved by calling updateMode with basically meaningless arguments, it seems it might be within LÖVE's reach to resolve the issue. Though reproducing the issue on anyone's computer other than mine seems to be the hardest part.

[slime]

updateMode will destroy and recreate the entire window and OpenGL context, which (aside from being noticeable to the user) has the side effect of clearing all Canvases - so if love did that internally, it would break a lot of games. It's definitely a good starting point for further investigation though.

(The underlying problem is also almost guaranteed to either be an issue in SDL's own source code or a bug in macOS itself, rather than something love's source code is doing on its own, so any fix or workaround is likely to happen in SDL's code rather than love's.)