DPI behavior on hybrid windows

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.

sorry if im missing something super obvious.

@boazrl Hi,

We are checking the issue. From the initial inspection, we have an issue, but we will need to check it in depth. I will update you.


1 Like


We can confirm that it’s a bug. We mark it as a high priority, and we will fix it in the next iteration.
I will update.


@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.


@eransharv thx for the update! missed the message…
I will verify the behavior tomorrow! thx for the update!

From my testing - it was not fixed (maybe just not pushed into the builds)
Hybrids still return window.devicePixelRatio as 1 on high dpi environments.

@boazrl, can you please tell me how exactly did you test it? I want to forward it back to the QA to recheck.

sure thing,

#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)

Thanks, we will do some tests to verify it, and I’ll update you here.

@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.

2021-08-30 16-58-42.zip (2.9 MB)


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!