Request: Per-pixel transparent, click-configurable Slate window in standalone/shipping (desktop overlays)

Development Rendering
, ,
1

I’d like to create a separate Slate SWindow—independent from the game viewport—that can be positioned anywhere on the desktop, with a fully transparent background (show desktop behind it), while still rendering Slate widgets on top so they appear “on the desktop.” This already works in the editor in some contexts, but I can’t get equivalent transparent behavior in standalone/shipping.

Motivation / Use cases

  • Companion HUD/overlay for streamers, tools, and second-screen-style UI.
  • Desktop “heads-up” utilities (perf, chat, or debug panels) controlled by the running game/tool.
  • Diegetic desktop widgets for creative apps.

Current behavior

  • Editor has some transparent window paths, but I can’t enable true per-pixel transparency for a separate Slate window outside the editor (standalone/shipping).
  • I don’t see a supported way to toggle desktop click-through vs hit-testable regions per widget.

Feature request (acceptance criteria)

  1. An API to create a Slate window with per-pixel transparency in standalone/shipping on desktop platforms.
  2. Ability to toggle click-through at the window level and/or supply a per-widget hit-test mask so only drawn widgets consume input.
  3. Z-order control for always-on-top (where the OS permits).
  4. Documented platform support matrix (Win/macOS/Linux) and any required project settings (RHI, swap chain flags, etc.).
  5. Minimal sample showing SWindow creation + a couple of Widgets on a transparent background.

What I tried

  • Creating an auxiliary SWindow via FSlateApplication::AddWindow(...) with transparency flags; works in editor but I can’t reproduce per-pixel transparency in standalone/shipping.
  • Platform hacks (Windows layered windows / DWM composition) aren’t available through public UE APIs without engine changes.

Nice-to-have API shape (illustrative)

TSharedRef<SWindow> Overlay = SNew(SWindow)
    .IsInitiallyMaximized(false)
    .SupportsMaximize(false)
    .Type(EWindowType::Normal)
    .AutoCenter(EAutoCenter::None)
    .Transparency(EWindowTransparency::PerPixel)           // new: enforce per-pixel
    .IsBackgroundTransparent(true)                         // new: desktop shows through
    .IsClickThrough(true)                                  // new: window ignores mouse (toggleable)
    .AlwaysOnTop(true);                                    // new or documented behavior

// Optionally: per-widget hit-test mask for non-rects
MyWidget->SetHitTestMask(SharedMaskTextureOrPath);

Questions

  • Is full per-pixel transparency in standalone/shipping currently supported anywhere?
  • If not, would Epic consider adding public APIs / project settings to support this?
  • Any guidance on the correct path to implement per-widget input regions over a transparent window?

Environment

UE 5.6 (Windows primary), running standalone and planning for shipping builds.

Thanks!

2

Steps to Reproduce

3

Hi,

We do have some plumbing in the engine for proper per-pixel transparency support, which we added at one point to try and support a shared notification window, but some Windows 11 issues at the time (plus lack of support on other platforms) caused us to shelf that effort. We haven’t done any testing around transparency support on newer Windows versions, but this define in GenericWindowDefinition.h may be what is causing it to not work in standalone:

#ifndef ALPHA_BLENDED_WINDOWS
	#define ALPHA_BLENDED_WINDOWS IS_PROGRAM || WITH_EDITOR
#endif

You could try modifying that to see if it’s working properly, but that path is currently unsupported so I wouldn’t be surprised if there are some bugs to deal with. I did try enabling the code compiled out by ONE_WINDOW_FOR_NOTIFICATIONS to see what state things are in, and changing SWindow::MakeNotificationWindow to create a per-pixel transparent window. However, I’m still seeing a black background behind the notifications (when testing via Slate.TestNotifications), so it’s likely that some additional work needs to be done here to get things working properly.

For your second question, I’m sure such a feature would be useful but we don’t have anything scheduled at the moment since it could be a pretty large feature to implement with a pretty niche use case. If you end up making engine changes to support this and want to push them back to the engine, you can send in Github pull requests and we’ll have the team review them. I’ll also note your interest with the editor team, though we can’t make any guarantees on if/when this would be implemented.

Your third question is probably the trickiest part, though it does look like we’re already applying WS_EX_LAYERED for per-pixel transparent windows. There may be some combination of style flags to prevent Windows from sending input messages on transparent pixels, but I’d need to do some experimenting to figure out how feasible that is (and other platforms would require bespoke implementation since this is all OS-specific).

Best,

Cody