Page 1 of 2
Correctly resizing window on HD monitor?
Posted: Wed Jul 24, 2019 8:08 pm
by 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!
Re: Correctly resizing window on HD monitor?
Posted: Thu Jul 25, 2019 11:38 am
by 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
Re: Correctly resizing window on HD monitor?
Posted: Thu Jul 25, 2019 2:24 pm
by 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
Re: Correctly resizing window on HD monitor?
Posted: Thu Jul 25, 2019 2:34 pm
by 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.
Re: Correctly resizing window on HD monitor?
Posted: Thu Jul 25, 2019 2:52 pm
by 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?
Re: Correctly resizing window on HD monitor?
Posted: Thu Jul 25, 2019 2:57 pm
by Sasha264
Wow!! The gif you shared looks really weird
I recommend to add it in your bitbucket ticket, because it perfectly describes the behavior.
Re: Correctly resizing window on HD monitor?
Posted: Thu Jul 25, 2019 9:14 pm
by 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.
Re: Correctly resizing window on HD monitor?
Posted: Fri Jul 26, 2019 6:31 pm
by 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:
- setMode / updateMode can resize window corectly on your secondary monitor
- 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.
Re: Correctly resizing window on HD monitor?
Posted: Mon Jul 29, 2019 3:43 pm
by 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.
Re: Correctly resizing window on HD monitor?
Posted: Mon Jul 29, 2019 6:22 pm
by 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.)