How to fix Windowed Fullscreen offset on a MacBook?

Development Programming & Scripting C++
, ,
1

When running in Windowed Fullscreen mode on a MacBook, there is a black bar added to the top of the screen to hide the camera notch.

However, the UMG Widget Blueprint components of the menu still track the cursor as if there was no top bar. The visual cursor and the clickable elements are offset. Hover and click events do not align with the visual cursor. For example, in the image, to click the middle right button, the user has to click as if they wish to use the top button.

This issue does not occur when in fullscreen mode.

What is causing this offset and how can it be fixed?

cursor_offset
cursor_offset1728×1117 200 KB

1 Like
2

I confirm this problem in UE5.4 too, with fullscreen same problem in my case

1 Like
3

There are a bunch of weird things with fullscreen and windowed fullscreen on MacOS with 5.4:

  • resolutions set in game changing resolution of the editor
  • fullscreen covering only a quarter of the screen
  • queried resolution options not being applied
  • multi-screen setups breaking everything where the game is on one screen but the UMG menu selection happening with the cursor on the other screen but nothing can be clicked
  • some crashes

Updating to 5.6 fixes some issues but introduces others, like the background blur in UMG no-longer working and the FPS on windowed fullscreen being limited to 60 whereas fullscreen gets 120.

It seems like fullscreen and UMG menus on MacOS are broken on a fundamental level.

1 Like
4

Engine: UE 5.4
Hardware: MacBook 16 M3 Max" (Apple Silicon, Retina/notch display)
Project: High-DPI enabled (Project Settings → Rendering → Allow High DPI in Game Mode = ON)
Modes affected: WindowedFullscreen (aka Borderless), Fullscreen
Modes not affected: Windowed (classic window with title bar) — works perfectly

Lyra game has same problems

Symptoms

  1. Mouse hover/click hit-boxes are vertically offset in WindowedFullscreen and (sometimes) in Fullscreen.
  • Offset equals approximately the height of the macOS menu bar / notch area.
  • The offset is only on Y (vertical). X is correct.
  • All UI widgets visually render at the right place, but Slate hit-testing and traces (hover/click) are “above” where they should be.
  1. Borderless (WindowedFullscreen) looks like it’s being sized to the full primary display, while Slate hit-test (and/or viewport) is laid out to the work area (desktop minus menu bar/dock).
  2. Fullscreen offers a set of resolutions that occasionally produce the same offset.
  • On a MBP 16", I’ve seen candidates like 2336×1510, 2624×1696, 2992×1934, 3456×2234.
  • All these resolutions are problematic, you need to subtract the height of the bar and then for the fullscreen mode they will work correctly, empirically I calculated that it is approximately 74 px. So 3456x2160 will fix the problem only in fullscreen mode!
  1. The shift problem is also observed in traces, for example if they are launched from the mouse

Hypothesis

  • On macOS with Retina + notch, Unreal + Cocoa have two coordinate spaces in play:
    1. Display work area (excludes menu bar/dock).
    2. Full display (includes menu bar/dock).
  • In WindowedFullscreen (borderless), the window sometimes gets sized to full display while the Slate hit-test tree is laid out against the work area, leading to a Y offset ≈ menu bar height.
  • In Fullscreen, enumerated modes can include “design-scale” or “points” style values, or pixel values with aspect ratios that don’t match native (or that exceed the usable area once the OS applies safe areas). Picking those can cause the same mismatch in vertical extent.
  • There’s also a timing/race aspect: macOS hides/shows the menu bar with an animation when apps enter full-screen. If metrics are sampled just before/after that transition, your window size and Slate’s notion of the viewport may temporarily disagree.