Per Pixel Transparency misbehaving/broken in 3.2.2-stable on Windows

[softgripper]

Godot version:
Godot_v3.2.2-stable_mono_win64

OS/device including version:
Windows 10 Home - 1909. Build - 18363.900
RTX 2080ti
GLES3 / GLES2

Issue description:
Starting borderless application at monitor resolution (1920x1080) with per pixel transparency allowed and enabled now hides the background applications, but shows my models.

Setting the application to 1920x1079 allows the applications behind to be seen. However clicks are trapped by application window.

Cursor clicks to not trickle through to the behind applications.

In Godot_v3.2.1-stable_mono_win64, the application would be transparent at 1920x1080, and clicks that weren't on my entities (ie, a mesh) would give control to applications in the background).

Steps to reproduce:
Create a new project.

Add a basic 3d spatial with a mesh and camera.

Project > Project Settings > General > Display > Window
Size >
Set width/height to the height of your monitor.
Check Borderless
Check Always On Top

Per Pixel Transparency >
Check Allowed
Check Enabled

Put a script on your root entity (eg, the Spatial)
Ensure the following is in the _Ready() method.

    public override void _Ready()
    {
        GetTree().Root.TransparentBg = true;
    }

Minimal reproduction project:
Attached is a simple project created in 3.2.1.
Run it in 3.2.1 mono and you will see the desired behavior a sphere, with transparent background and you are able to operate on elements behind the application (eg, windows desktop or other apps).

Run it in 3.2.2 and you will see a black screen with a sphere. The transparency will work if you resize the window in the application settings, however all the cursor interactions will still be trapped.

• NOTE:
  You will not be able to reopen it in 3.2.1 after opening in 3.2.2 because it changes the SLN file (really annoying - not sure if another bug). So if you want to retest - just extract from the zip again.

BugReport.zip

[Calinou]

@softgripper Can you test this in the various 3.2.2 betas and RCs to make it easier to bisect the regression? You can download them here.

You will not be able to reopen it in 3.2.1 after opening in 3.2.2 because it changes the SLN file (really annoying - not sure if another bug). So if you want to retest - just extract from the zip again.

This is because the way the SLN is generated has changed to allow moving/removing scripts from the FileSystem dock without breaking stuff. In any case, I'd recommend using GDScript for minimal reproduction projects so everyone can try them locally (not just people with Mono-enabled builds).

[akien-mga]

It's probably related to #38629 (CC @bruvzg @Technohacker).

[bruvzg]

However clicks are trapped by application window.

Change in click-through behavior of the windows is probably caused by #38629 (it's now uses more efficient per-pixel transparency method), but it's in general inconsistent between different OSs and DMs.
You should not expect clicks to go through transparent areas. There's Windows API to specify clickable area but it's not currently not available from Godot (and there's no straightforward method to incorporate it to the current transparency implementation, since it uses polygon not the image buffer, see SetWindowRgn), on macOS similar probably can be done by changing ignoresMouseEvents if mouse is outside the shaped.

Starting borderless application at monitor resolution (1920x1080)

Transparency is not supported in full screen mode (on any platform), and on Windows borderless window with the screen resolution seems to be identical to fullscreen.

[Technohacker]

I checked the MS docs and the previous method allowed clicks to pass through:

Hit testing of a layered window is based on the shape and transparency of the window. This means that the areas of the window that are color-keyed or whose alpha value is zero will let the mouse messages through. However, if the layered window has the WS_EX_TRANSPARENT extended window style, the shape of the layered window will be ignored and the mouse events will be passed to other windows underneath the layered window.

The current method (DwmEnableBlurBehindWindow) is consistent with macOS and Linux, as in it won't allow clicks to pass through

[softgripper]

@softgripper Can you test this in the various 3.2.2 betas and RCs to make it easier to bisect the regression? You can download them here.

Appears to have been introduced in beta3.

Bug not in Godot_v3.2.2-beta2_win64

Bug present in Godot_v3.2.2-beta3_win64

You will not be able to reopen it in 3.2.1 after opening in 3.2.2 because it changes the SLN file (really annoying - not sure if another bug). So if you want to retest - just extract from the zip again.

This is because the way the SLN is generated has changed to allow moving/removing scripts from the FileSystem dock without breaking stuff. In any case, I'd recommend using GDScript for minimal reproduction projects so everyone can try them locally (not just people with Mono-enabled builds).

Done - attatched is a version using GDScript.

BugReport.zip

[softgripper]

Transparency is not supported in full screen mode (on any platform), and on Windows borderless window with the screen resolution seems to be identical to fullscreen.

Currently my application in 3.2.1 allows for interacterable characters to run around on the windows desktop without hindering the functionality of other apps, and it's fantastic. It is only after 3.2.2 beta3 that this is no longer possible.

[Technohacker]

@softgripper It's definitely my change to use DwmEnableBlurBehindWindow then. The older method using WS_EX_LAYERED gives you clickthrough support but at the cost of a CPU bottleneck. You can always revert my commit and build the engine to bring that support back :)

[softgripper]

Done - attatched is a version using GDScript.

BugReport.zip

In this zip, the height has been set to 1079 so the screen may not appear black.

After testing the other RC/Betas, "Always on Top" has stopped working even when opening the project with 3.2.1. I'll try after a reboot, but at the moment it's 2am here, I'll have a look in the morning..

[softgripper]

@softgripper It's definitely my change to use DwmEnableBlurBehindWindow then. The older method using WS_EX_LAYERED gives you clickthrough support but at the cost of a CPU bottleneck. You can always revert my commit and build the engine to bring that support back :)

Technohacker - I'd love to, however I'm unfamiliar with C and C++, so not comfortable doing this unless there is a simple "revert" button. (If it was any of the other 10+ languages I'm familiar with, no problem).

[Technohacker]

@softgripper I can guide you through :)

1. Do a git clone of the repo
2. git revert 5d2683 then save the commit message file so git does the revert
3. Build using these instructions

I don't anticipate this commit being reverted upstream because it brings a more consistent API to all desktop platforms 😅

[softgripper]

@softgripper I can guide you through :)

1. Do a git clone of the repo
2. git revert 5d2683 then save the commit message file so git does the revert
3. Build using these instructions

I don't anticipate this commit being reverted upstream because it brings a more consistent API to all desktop platforms 😅

Got halfway through the build then decided to do some performance tests. My system is pretty decent (32gb, 8700k, 2080ti).

The old way yields about 63fps - so basically unacceptable. The new way is rock solid at my capped fps (144, or 240 depending on gsync monitor) - I haven't tried uncapped, but it will be insane.

I was basically using the build for debugging as I export this stuff to WASM and use it as interactive transparent overlays on twitch, so my usecase still works.

I noticed things were different (including the propagated "click through"), so I raised the bug.

My overlays still work correctly, so I don't see a real need for the revert.

That being said, the click through thing would be nice to have. You could have an app run a whole heap of real time widgets (stock market tickers, round clocks, live feeds etc) and position them wherever you like on your desktop, or some tamagotchi type creature you keep alive while working. Hopefully this is something that Godot can achieve in the future. I'm not sure what other use cases there would be for transparency if it's limited to rectangles that can't have pass through input.

At any rate, I got stuck at the "saving the commit message". I did get the existing git build working though, so might go teach myself some CPP and dig around. I've been messing with Vulkan in Rust - and it's interesting :)

Thanks for your time and work @Technohacker

[Technohacker]

I would say having support for multiple windows would be a great way to have a widget style application, because each window could shrink itself to fit its contents exactly. One workaround as of now is to launch the project within itself again with different launch flags using OS.execute and change code paths depending on them. Fairly clunky, I know, but multi window could simplify that :)

[bruvzg]

I have opened WIP PR for click-through support, clickable area can be specified as a polygon (Path2D node for example), in works independently of transparency (currently tested only on macOS) - #39944 (for 4.0), the same changes for 3.2 are in click-through-3 branch.

[akien-mga]

I added a comment linking to this issue in the 3.2.2 release's "Known incompatibilities" section.

As it's not a bug but a necessary compatibility breakage to fix performance and cross-platform behavior, I'll close this.

But as mentioned by @bruvzg, the feature might come back as independent of per pixel transparency with #39944.