UI Canvas bugs on non-native resolution?

My interface scaled nicely in 5.2 (since the dx9 canvas-breaking-fix and dx11 letterbox fix), but in 5.3.0b5 If I change the resolution to something below native shifts both the visual part of the interface to the right some amount, and the 'physics' part of the ui that's raycasted etc seems to also shift upwards.

Anyone else stumbled across this? If there's some confirmation or desire I'll try to make a demo scene of it.

Edit: Forgot to mention: it seems to work fine in the editor, only the build shows this. Dx9 / dx11 / glcore all seem to show it

 

Could you file a bug on it i havn't heard of this before.

 

Filed a bug report, named "Canvas elements at wrong location at non-native resolution". I'm not sure if it has come through; the bug reporter froze after the progress bar of sending it completed and disappeared. I'll post link if I receive it.

Edit: If not, I'll try again in an hour or so.

 

Well. My bug reporting tool seems broken. But it's simple enough to replicate. An empty scene with a single button centered to the middle is all that's needed. In the editor, the button will correctly stay in the middle with switching resolutions. In the player, the button will shift to the right or even out of screen at a low enough resolution. The selection box gets some additional translation upwards.

Obviously this behaviour wasn't in 5.2.

Some example pics I uploaded here: http://imgur.com/a/UriWg

Spoiler: Button at 1920x1080

Spoiler: Button at 1366x768

Spoiler: Button at 1024x768

Sadly enough my mouse isn't visible on them, but at the first it's on the object, the 2nd it's about 100 px above it and the third about 200 or so.

 

So it's back. With a vengeance.

If you have a Windows standalone build and set the full screen resolution to a non-native resolution, through the resolution dialog or through Screen.SetResolution() in-game, the UI will be contorted and the hit detection will be off.

On a positive note the "Default is native resolution" defaulting to 1024x768 bug, seems to be partially resolved in that when you disable the resolution dialog and enable "Default is Full Screen", the build will actually run in the native desktop resolution correctly.

So the workaround at the moment is to disallow changing to non-native resolutions when the game is in full screen mode.

 

@movra I believe it's a different bug. That bug was either the dx9 one, where the canvas simply stopped rendering, or the dx11 one, that messed up all rendering. This time around, the rendering itself seems all fine; it's only the canvas rendering that's having a bit of a brain fart. Oh, and it appears to be there on dx9/dx11 and opengl as well.

 

@Zuntatos With the linked thread I'm referring to the issue where QA consistently misses obvious resolution problems with Windows standalone builds. And this has been going on since at least June!

 

@movra Ah, that's very true. I suppose they do not have unit tests involving resolution changes.

 

I'm not sure if you can unit test these kind of UI problems, but you could at least have an automated test that checks if the standalone player matches a reference image, and repeat that test for several resolutions.

Actually the bare minimum would be to have an intern manually build and run an otherwise empty default project with just one button and one cube in it.

I expected better after this:

 

@movra Update on the bug report; got reproduced by QA and sent to devs

 

Small update; with 2 screens, main 1920x1080 and secondary 1680x1050, playing on the 1080p screen seems to make the canvas bug appear on any resolution except 1680x1050.

 

Bump for attention as it's quite a nasty blocking bug. No progress afaik, changelog doesn't list it as fixed nor as known issue.

 

Only recently investigated, and likely due to multi-display support. Fix being vetted and working on getting inbound. Will likely disable the mix of multi-display and UI for the time being.