Suddenly all hybrid windows that we use are affected by DPI (they did not in the past), what’s worse is they are getting the wrong window.devicePixelRatio value - it’s always 1 even though it’s 1.75 when tested.
without knowing whats the dpi I’m kinda clueless as to how to fix those windows, tried all the voodoo manifest flags - nothing - checked some other apps - same behavior - native “desktop only” windows receive the correct value - hybrid receives 1.
tested on 175% scale
Predator - main window has the wrong value (1) , the second screen is fine (1.75)
Craft a lot - main window has the wrong value (1) , the second screen is fine (1.75)
Lol wiz - desktop only but not native has the wrong value (1) and gets stretched out of the screen.
valoplant hello window - native desktop only (1.75 )
best solution IMO would be to have the platform ignore the DPI like in the good old days (up until this month?) - but if its not possible to revert back to that, a method to receive the true scale would be great.
@boazrl, this issue is fixed on version 0.174. We will release it to the developer’s channel tomorrow probably. Please stay tuned to our announcement on slack about the release.
steps: #get an app with a hybrid window (LoLwiz’s desktop window \ Predator’s desktop window \ Craft-a-lot main window are some of the examples I can quickly think of) #change your screen scale to x > 100%. #inspect the now enlarged window with the inspect window → go to console and type window.devicePixelRatio
the result I’m receiving (and just verified it again as I type this) is 1. even though the scale on my screen is set to 175% (just for the test, I’m not weird like that).
I want to stress again that this was NOT the behavior some time ago, hybrids used to completely ignore DPI.
here is a picture of the test I just did (using wiz since Pred on 175% would not leave any room on 1920*1080)
@boazrl, after DPI change, you should restart OW to get the correct devicePixelRatio.
If you are working with two screens, note that for non-native windows, the DPI calculations are affected only by the DPI of the primary window, regardless of which monitor you opened the window on.
i.e., if the window is on a 100% DPI monitor but the main monitor is 125% - it will resize based on 125%.
And of course, the window.devicePixelRatio will return 1.25.
tested with a complete OW restart, and as you said it did show the primary screen DPI.
the window DOES change the size when dragging it to another window (the secondary 100% one) - but the device pixel ratio did NOT change and kept saying 1.25. so again the data will not match reality.
attached a video showing the behavior I described.
imo this is just as bad as always saying 1… wrong data is wrong data.
I need to test and discuss the issue internally, but maybe this workaround can work: (didn’t test it yet, just thinking out loud here).
Basically, once the drag of a non-native window is completed (assuming the DPI between the screens is different, of course) - you will get a “wrong” size of the window - as the dragMove of a non-native window is not DPI-aware.
In that stage, you can call getMonitorsList(), extract the monitor’s array that can give you info about the DPI of each monitor (dpiX=96 mean 100%, dpiX=120 means 120%, etc.) - do the right calculation and change the size to the “right” size.
The user will see a “jump” between the size for a second, but that can work.
As mentioned, let me test and discuss how we can get the best solution for it.
Hi Eran, I have some vague memory of going down that path and hitting another bump, but I really can’t say for sure…
I will have a look and try it once some time clears up for DPI works.
Thx for caring enough to think outside of the box to try and find a quick solution!