WebGL Screen width, Camera.pixelWidth, and Camera.scaledPixelWidth all wrong on Retina display

…but only if the web page initially loads on a Retina display. If I load it on my second (non-Retina) monitor, and then move it over to the Retina display, then it seems correct.

Here’s what I get when I load (or reload) the web page on a Retina display:


Note the debug info at the bottom of the screen. That (1992.0, 697.0) is the direct Input.mousePosition value when the mouse is near the upper-right corner of the game. To the right are the values of Screen.dpi (always 0) as well as Screen.width/height, Camera.pixelWidth/pixelHeight, Camera.scaledPixelWidth/scaledPixelHeight, and what I get from doing Camera.viewportToScreen(Vector3.one). All these report a display size of 1024x768. Yet Input.mousePosition (which is supposed to be in pixelWidth/pixelHeight coordinates) is giving me values twice as big.

When I drag the window over to my second (non-Retina) monitor and repeat the test, I get this:


Now the screen and camera are still reporting the display size as 1024 by 768 (which is what I requested in the build settings, BTW). But Input.mousePosition actually agrees: a point near the upper-right corner is reported as 997, 731.

Now I drag the browser window back to my Retina display, and get:


This time, for the first time, the screen size and camera sizes all say the display is 2048 x 1536 (exactly twice what I requested in the build settings). And this matches what Input.mousePosition reports, so I am able to correctly convert to my own coordinate system.

It’s puzzling that Camera.pixelWidth and Camera.scaledPixelWidth are the same under all circumstances; I thought the point of these was to report different values, in cases where we are on a scaled (double-resolution) display. But whatever. The real problem for me is that on initial load on a retina display, all ways of reporting the screen size flat-out lie, at least compared to what Input.mousePosition reports. And I can find no way of knowing when this is the case, short of asking the user to manually calibrate the mouse (which sucks).

EDIT: another weird observation: when things are working (i.e. on a non-Retina display, or moved to a Retina display from a non-Retina display), Input.mousePosition reports 0,0 at the bottom-left corner of the display. But when loaded on a Retina display, Input.mousePosition reports 0,0 at the middle-left side of the display. That’s why my computed Y values happen to look correct in all three cases above, when testing with a mouse pointer near the top of the screen. (That’s just coincidence; the computed values are wrong everywhere else.)

Has anyone else run into this? Any suggestions for a work-around?

Well, nuts. Nobody has any ideas?

Hi @JoeStrout ,

Could you please tell me which Unity version you’re on? We’ve recently fixed bugs related to incorrect mouse positions on WebGL, it’ll help to know if what you’re seeing is in a version before the fixes were merged/backported.

Would you be willing to open a bug report with a repro project for us to quickly see if this is a new issue?

Thanks :slight_smile:

1 Like

This is in 2019.3.15f1. Do you happen to know the oldest version to which the fix was backported?

The fixes are currently in 2022, 2021.2, and 2021.1. The backports for 2020.3 and 2019.4 are scheduled.

If you can test your project with one of the fixed versions, and report back, that’d be a great help. If the issue is still present, then a bug report would be the way forward for us to dig into this and fix it.

Well, I’ve confirmed that the bug still exists in the last LTS release, 2020.3.22f1. Plus that version (but not 2019LTS) introduces an exciting new bug where only the bottom-left quarter of the display is drawn, but doubled in size:


It’s related, somehow, as when I scribble with the mouse (what this demo/test program does) the lines are appearing on the screen in about where they should be, if the screen weren’t drawn twice as big. But we’ve just swapped one bug for another. (Just tried 2021.1.28, and it behaves the same way.)

I’m installing 2021.2.1f1 now to see if we manage to get correct mouse input and correct display at the same time! If either problem is still occurring there, I’ll make a simple example and file a bug report. Just wanted to update anyone who may be following this thread.

EDIT: Well, nuts. I can’t get 2021.2 to build for WebGL at all due to this error . Feeling a bit stuck here… I’m playing Version Roulette, and it appears that all the chambers are loaded. :frowning:

If the bug fixes I mentioned earlier do indeed fix this issue, then it’s expected that you’re seeing it in 2020.3 since we haven’t backported them to 2020 and 2019 yet (I’m working on them now :smile:). I replied to your other thread about the error you’re seeing in 2021.2, hopefully we can get your project to open there.