starred/mumble-mumble-voip

Fork 0

mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00

Remembering previous size and position wrong in mixed DPI situation #2581

New issue

Open

opened 2026-02-20 22:09:07 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-20 22:09:07 -05:00

Owner

Originally created by @lePoMo on GitHub (Sep 25, 2022).

Description

I have two screens at different DPI scaling on Windows 10.

primary screen, to the left = 150% display scaling (4K display)
secondary screen, to the right = 100% display scaling (1280x1024 in portrait)

Mumble client resides on secondary screen. (not fullscreen).

When closing and reopening mumble, it will open at a much smaller size, and at a position slightly more to the top left.
Screenshots attached below.

Quickly comparing the window size, it is in fact smaller at a factor of 150%.
(682 pixels wide to 454 pixels wide, 682/454 = 1.502..)

Steps to reproduce

move window to secondary screen which is at a different DPI than primary screen
close window
reopen window - size will be different (much smaller in my case), position will be slightly different

Mumble version

1.4.287

Mumble component

Client

OS

Windows

Reproducible?

Yes

Additional information

works as expected when closing and re-opening on primary screen: reopens at the same size and position (note: I did not measure pixels)
bug also happens when mumble window does not touch the border of the screen (tested at the center of the secondary screen) : So not related to it almost touching the primary screen, which with the position bug could have had it pick dpi from wrong screen.
this problem is not new. I can't say how old, because I only have a second screen since <1 year.
this bug may go back to at least 2017, seeing issue #3248 sounding similar (only open issue I found that sounds similar). I did a new issue because two much may have changed since, and that issue is not very detailed.
I am currently working around this by using PowerToys FancyZones with the option the restore the window at its previous zone. Note this is not ideal because it rarely triggers what is maybe an other bug: mumble window contents did once not resize to the bigger window, but this may even be a qt problem. (I only set this up now, so only 5 tries so far). If I encouter this more often, I will do a separate bug report.

Relevant log output

No response

Screenshots

Size as set by me:
2022-09-25 mumble 1 4 287 - window size - 1 - size set by me

Size after closing and reopening:
2022-09-25 mumble 1 4 287 - window size - 2 - size after closing + reopening once

Size after closing and reopening a second time:
2022-09-25 mumble 1 4 287 - window size - 3 - size after closing + reopening second time

Position and size as set by me:
2022-09-25 mumble 1 4 287 - window size and position on screens - 1 - size+pos as set by me

Position and size after closing and reopening:
2022-09-25 mumble 1 4 287 - window size and position on screens - 2 - size+pos after reopening

Position and size after closing and reopening a second time:
2022-09-25 mumble 1 4 287 - window size and position on screens - 3 - size+pos after reopening second time

Originally created by @lePoMo on GitHub (Sep 25, 2022). ### Description I have two screens at different DPI scaling on Windows 10. * primary screen, to the left = **150%** display scaling (4K display) * secondary screen, to the right = 100% display scaling (1280x1024 in portrait) Mumble client resides on secondary screen. (not fullscreen). When closing and reopening mumble, it will open at a much smaller size, and at a position slightly more to the top left. Screenshots attached below. Quickly comparing the window size, it is in fact smaller at a factor of **150%**. (682 pixels wide to 454 pixels wide, 682/454 = 1.502..) ### Steps to reproduce 1. move window to secondary screen which is at a different DPI than primary screen 2. close window 3. reopen window - size will be different (much smaller in my case), position will be slightly different ### Mumble version 1.4.287 ### Mumble component Client ### OS Windows ### Reproducible? Yes ### Additional information * works as expected when closing and re-opening on primary screen: reopens at the same size and position (note: I did not measure pixels) * bug also happens when mumble window does not touch the border of the screen (tested at the center of the secondary screen) : So not related to it almost touching the primary screen, which with the position bug could have had it pick dpi from wrong screen. * this problem is not new. I can't say how old, because I only have a second screen since <1 year. * this bug may go back to at least 2017, seeing issue #3248 sounding similar (only open issue I found that sounds similar). I did a new issue because two much may have changed since, and that issue is not very detailed. * I am currently working around this by using PowerToys FancyZones with the option the restore the window at its previous zone. Note this is not ideal because it rarely triggers what is maybe an other bug: mumble window contents did once not resize to the bigger window, but this may even be a qt problem. (I only set this up now, so only 5 tries so far). If I encouter this more often, I will do a separate bug report. ### Relevant log output _No response_ ### Screenshots Size as set by me: <img width="341" alt="2022-09-25 mumble 1 4 287 - window size - 1 - size set by me" src="https://user-images.githubusercontent.com/14861323/192153105-2f02f758-0cc9-4bbb-94b4-7ff89859f485.png"> Size after closing and reopening: <img width="227" alt="2022-09-25 mumble 1 4 287 - window size - 2 - size after closing + reopening once" src="https://user-images.githubusercontent.com/14861323/192153145-9de59489-5209-43bc-bebc-62dd97b60685.png"> Size after closing and reopening a second time: <img width="151" alt="2022-09-25 mumble 1 4 287 - window size - 3 - size after closing + reopening second time" src="https://user-images.githubusercontent.com/14861323/192153167-375e4aba-eff0-44f6-aa4c-2963a65d6215.png"> Position and size as set by me: <img width="2432" alt="2022-09-25 mumble 1 4 287 - window size and position on screens - 1 - size+pos as set by me" src="https://user-images.githubusercontent.com/14861323/192153259-51b189eb-5643-4375-ad74-1e53e28e8b66.png"> Position and size after closing and reopening: <img width="2432" alt="2022-09-25 mumble 1 4 287 - window size and position on screens - 2 - size+pos after reopening" src="https://user-images.githubusercontent.com/14861323/192153292-a0625b33-8ed3-48a4-a433-434d5d4581ca.png"> Position and size after closing and reopening a second time: <img width="2432" alt="2022-09-25 mumble 1 4 287 - window size and position on screens - 3 - size+pos after reopening second time" src="https://user-images.githubusercontent.com/14861323/192153311-1d6fd786-8b7d-4114-9a74-3462d606b62d.png">

deekerman added the

client

bug

labels

2026-02-20 22:09:07 -05:00

deekerman commented

2026-02-20 22:09:08 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Sep 26, 2022):

Does the issue also occur, when you

use both screens at 100% display scaling
use both screens at 150% display scaling

I think this is probably somehow related to the way we save and restore the window's geometry and position (by means of save/restoreGeometry. E.g.
github.com/mumble-voip/mumble@600ffb476a/src/mumble/MainWindow.cpp (L443-L446)

@Krzmbrzl commented on GitHub (Sep 26, 2022): Does the issue also occur, when you - use both screens at 100% display scaling - use both screens at 150% display scaling I think this is probably somehow related to the way we save and restore the window's geometry and position (by means of save/restoreGeometry. E.g. https://github.com/mumble-voip/mumble/blob/600ffb476a62901d374926cf8cab6875f4c93bbf/src/mumble/MainWindow.cpp#L443-L446

deekerman commented

2026-02-20 22:09:09 -05:00

Author

Owner

@lePoMo commented on GitHub (Sep 26, 2022):

I now did those two tests. Both worked perfectly, The window reopened exactly where it was closed, and at exactly the same dimensions (both to the pixel).

I did more tests:

NewTest1

primary screen at 150%, secondary screen at 100%, Mumble client on secondary screen. Close window.
switch primary screen to 100%
reopen Mumble client

Effect: it opens at the same dimensions as when closed.

NewTest2

primary screen at 100%, secondary screen at 100%, Mumble client on secondary screen. Close window.
switch primary screen to 150%
reopen Mumble client

Effect: it opens too small (like in my first post)

NewTest3 - the inverse of my initial bug report

primary screen at 100%, secondary screen at 150%, Mumble client on secondary screen. Close window.
no change to screens
reopen Mumble client

Effect: it opens too big and position moves slightly down and to the right. (This seems coherent with my initial report, where it got smaller and slightly moved to the top left when primary at 150% and secondary at 100%)

My assumption

though not sure if sound

dimensions are correctly saved, but wrongly applied during loading.
during restoring the loaded dimensions, one or more display metrics during some math are wrongfully taken from the primary screen instead of from the screen the window goes on.
Hence when both screens have same dpi, the bug is hidden
Hence the bug does not happen if the window is closed and reopened on the primary screen (when primary 150, secondary 100)
And hence when the secondary screen has smaller dpi, the window dimensions shrink, and vice versa the dimensions increase when the secondary has higher dpi than the primary screen.

reason for saying "one or more display metrics": while never having worked with qt, I know window decoration metrics are their own source of problems when positioning windows programmatically. Since they're also different on both screens, they may account for the window slightly moving around. (Imo best tracking down the dimensions bug first, maybe the position problem goes away with it).

--
The following two also tested, but now noticing that there is no right answer for these, because I am switchting the secondary screen dpi. Maybe they can still help nonetheless:

NewTest4

primary screen at 150%, secondary screen at 100%, Mumble client on secondary screen. Close window.
switch secondary screen to 150%
reopen Mumble client

Effect: it opens at the same dimensions as when closed (relative to the screen size), meaning same outline, less visible content (because of bigger font/icons).

NewTest5

primary screen at 150%, secondary screen at 150%, Mumble client on secondary screen. Close window.
switch secondary screen to 100%
reopen Mumble client

Effect: it opens at smaller dimensions than when closed (relative to the screen size), meaning exact same visible content

@lePoMo commented on GitHub (Sep 26, 2022): I now did those two tests. **Both worked perfectly**, The window reopened exactly where it was closed, and at exactly the same dimensions (both to the pixel). I did more tests: ### NewTest1 1. primary screen at 150%, secondary screen at 100%, Mumble client on secondary screen. Close window. 2. switch primary screen to 100% 3. reopen Mumble client Effect: it opens at the same dimensions as when closed. ### NewTest2 1. primary screen at 100%, secondary screen at 100%, Mumble client on secondary screen. Close window. 2. switch primary screen to 150% 3. reopen Mumble client Effect: it opens too small (like in my first post) ### NewTest3 - the inverse of my initial bug report 1. primary screen at 100%, secondary screen at 150%, Mumble client on secondary screen. Close window. 2. no change to screens 3. reopen Mumble client Effect: it opens too big and position moves slightly down and to the right. (This seems coherent with my initial report, where it got smaller and slightly moved to the top left when primary at 150% and secondary at 100%) ### My assumption though not sure if sound * dimensions are correctly saved, but wrongly applied during loading. * during restoring the loaded dimensions, one or more display metrics during some math are wrongfully taken from the primary screen instead of from the screen the window goes on. Hence when both screens have same dpi, the bug is hidden Hence the bug does not happen if the window is closed and reopened on the primary screen (when primary 150, secondary 100) And hence when the secondary screen has smaller dpi, the window dimensions shrink, and vice versa the dimensions increase when the secondary has higher dpi than the primary screen. reason for saying "one or more display metrics": while never having worked with qt, I know window decoration metrics are their own source of problems when positioning windows programmatically. Since they're also different on both screens, they may account for the window slightly moving around. (Imo best tracking down the dimensions bug first, maybe the position problem goes away with it). -- The following two also tested, but now noticing that there is no right answer for these, because I am switchting the secondary screen dpi. Maybe they can still help nonetheless: ### NewTest4 1. primary screen at 150%, secondary screen at 100%, Mumble client on secondary screen. Close window. 2. switch **secondary** screen to 150% 5. reopen Mumble client Effect: it opens at the same dimensions as when closed (relative to the screen size), meaning same outline, less visible content (because of bigger font/icons). ### NewTest5 1. primary screen at 150%, secondary screen at 150%, Mumble client on secondary screen. Close window. 2. switch **secondary** screen to 100% 3. reopen Mumble client Effect: it opens at smaller dimensions than when closed (relative to the screen size), meaning exact same visible content

deekerman commented

2026-02-20 22:09:09 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Sep 27, 2022):

Yeah, I think your display metrics theory sounds very likely. The only question remaining is whether this is a bug in our code base or a bug somewhere in Qt.

Do you have other Qt programs installed on your system? If so, do they suffer from the same issues?

@Krzmbrzl commented on GitHub (Sep 27, 2022): Yeah, I think your display metrics theory sounds very likely. The only question remaining is whether this is a bug in our code base or a bug somewhere in Qt. Do you have other Qt programs installed on your system? If so, do they suffer from the same issues?

deekerman commented

2026-02-20 22:09:09 -05:00

Author

Owner

@lePoMo commented on GitHub (Sep 27, 2022):

Do you have other Qt programs installed on your system? If so, do they suffer from the same issues?

I have DupeGuru installed on my system (a duplicate file finder), it uses Qt and does not suffer from the same issues.
https://github.com/arsenetar/dupeguru/

@lePoMo commented on GitHub (Sep 27, 2022): > Do you have other Qt programs installed on your system? If so, do they suffer from the same issues? I have **DupeGuru** installed on my system (a duplicate file finder), it uses Qt and does not suffer from the same issues. https://github.com/arsenetar/dupeguru/

deekerman commented

2026-02-20 22:09:09 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Sep 28, 2022):

Okay, then the issue is probably somewhere in our code.

@Krzmbrzl commented on GitHub (Sep 28, 2022): Okay, then the issue is probably somewhere in our code.

deekerman commented

2026-02-20 22:09:09 -05:00

Author

Owner

@Aqualie commented on GitHub (Feb 25, 2023):

I have this issue as well everytime I open Mumble the window size and position is wrong. All my other applications don't have this problem.

@Aqualie commented on GitHub (Feb 25, 2023): I have this issue as well everytime I open Mumble the window size and position is wrong. All my other applications don't have this problem.