Bug in cursor position scaling on secondary monitors

Development Programming & Scripting UI
, ,
1

Hi,

This is a question related this issue:

[[BUG] Regarding “UE-206910” Cursor input does not work properly in exclusive fullscreen mode on a secondary [Content removed]

In this method:

FPointerEvent FSlateApplication::TransformPointerEvent(const FPointerEvent& PointerEvent, const TSharedPtr<SWindow>& Window) const
{
    FPointerEvent TransformedPointerEvent = PointerEvent;
    if (Window)
    {
       if (TransformFullscreenMouseInput && !GIsEditor && Window->GetWindowMode() == EWindowMode::Fullscreen)
       {
          // Screen space mapping scales everything. When window resolution doesn't match platform resolution, 
          // this causes offset cursor hit-tests in fullscreen. Correct in slate since we are first window-aware slate processor.
          FVector2f WindowSize = Window->GetSizeInScreen();
          FVector2f DisplaySize = { (float)CachedDisplayMetrics.PrimaryDisplayWidth, (float)CachedDisplayMetrics.PrimaryDisplayHeight };
 
          TransformedPointerEvent = FPointerEvent(PointerEvent, PointerEvent.GetScreenSpacePosition() * WindowSize / DisplaySize, PointerEvent.GetLastScreenSpacePosition() * WindowSize / DisplaySize);
       }
    }
 
    return TransformedPointerEvent;
}

TransformFullscreenMouseInput can be toggled via the cvar Slate.Transform.FullscreenMouseInput=0

Doing so solves the original issues for our projects, but I’ve never seen this fixed mentioned in any related questions on UDN.

I’m a bit confused about the initial function this scale on the cursor position tried to accomplish.

For us, when in dedicated fullscreen mode, the window and display size appear to always be the same.

So my questions are the following:

1 - Is it safe to disable the cvar to fix the multi monitor setup fullscreen issue ?

2 - What was the original intent of this code path, in what cases is it needed ?

Thank you !

[Attachment Removed]

2

Steps to Reproduce[Attachment Removed]

3

Hi,

The fix handles cases where you’re in exclusive fullscreen at a resolution that doesn’t match your native. For instances, if you called “r.setres 1920x1080f” on a 4k monitor, the application and back buffer would be 1920x1080, but the OS would stretch that window to the full screen. Before that change, the mouse events would be completely off since the application was unaware of the stretching.

That said, running exclusive fullscreen at non-native resolutions is almost always a bad idea and we prefer to use borderless windowed mode and adjust other knobs to lower the resolution at the engine level if needed for perf, and I’ve certainly seen many recent games not even expose an option for exclusive fullscreen. I’m not sure anyone had explored disabling that cvar as a workaround for the multi-monitor issue, but I think it’s safe to do so unless you’re set on supporting non-native exclusive fullscreen resolutions.

Best,

Cody

[Attachment Removed]

4

Hi,

I verified (on 5.8 using Lyra) that “setres 1920x1080f” on my 4k monitor will stretch the window to take the full monitor, though it seemed like input was working properly regardless of the value of Slate.Transform.FullscreenMouseInput. It’s certainly possible that OS updates or some changes to dx12 has rendered that fix unnecessary, though we’d need to do more testing before I’d be comfortable changing the default since it could cause a pretty confusing change in functionality. That said, I don’t see any problem with disabling it in your project if you’re seeing better results.

[Attachment Removed]

5

Hi,

I’ve seen 2 different behaviors from using r.setres to resize the game (while in dedicated FS mode). Both seem to prefer Slate.Transform.FullscreenMouseInput=0.

On our UE5.5 title, the game is resized to take 1/4th of the screen. using Slate.Transform.FullscreenMouseInput=0 fixes a UI scaling issue in this case.

On our UE5.7 title, the OS resize the display to 1080p when using r.setres, so Slate.Transform.FullscreenMouseInput has no impact on the UI since the game resolution is the same as the display resolution. It does however fixes the original issue of moving the game to another display of a different native resolution.

I’ve not seen a case where a 1080p game viewport would be stretched over a 4k display yet. I’ve tried with different upscaling methods, and no upscaling too.

Maybe it requires a combination of cvars we’re not using, or it’s some engine modifications we did. I’ll try to validate this in unreal vanilla.

Thanks!

Xavier

[Attachment Removed]