[Bug]: window transparency not respected (black background) on some systems with hardware acceleration enabled

[Galkon]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

25, 26, 27

What operating system are you using?

Windows

Operating System Version

Windows 10, Windows 11

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

When setting these options on a new BrowserWindow, the window should always be transparent regardless of whether or not hardware acceleration is enabled:

new BrowserWindow({
  frame: false,
  transparent: true,
  alwaysOnTop: true
})

Actual Behavior

For some reason, for some people, electron does not respect the transparency or a transparent background color (such as #00000000) and it has a black background when hardware acceleration is enabled.

It appears the issue is resolved when disabling hardware acceleration. Similar to this issue it seems.

Testcase Gist URL

https://gist.github.com/Galkon/c5e195442696a324afa03d9c391e8893
Sample App

Additional Information

Context

Context: We are using electron for a screen overlay at Medal.tv. For everyone on our team, there are no issues with transparency. However, there are some users using our production app which have this issue.

In our app we are still using electron 22 for win 7/8/8.1 compatibility, but I have verified this problem still exists in 25, 26, and 27 (side note, 27 is plagued by this bug too).

Disabling hardware acceleration is a less-than-ideal solution because our app is video-based and you cannot disable it per-window, only for the entire app.

Debugging

I've created a sample app which currently can run 15 different test scenarios, all of which still produce a black window for affected users when it should be transparent.

The tests it runs include 15 variations of the following:

• Setting the window size to be smaller than display width / height (mentioned in this issue)
• backgroundColor set to #00000000 or not set (related issue here?)
• Delaying window show vs show: true on BrowserWindow initialization
• Disabling thickFrame
• Setting backgroundMaterial to none
• Setting hasShadow to false
• Calling setBackground('#00000000') after initialization
• Manually controlling window size via setBounds and setContentSize
• Manually calling setAlwaysOnTop after initialization

System Specs

I've been able to grab some specs of users systems, but I cannot find any correlating factors. It has happened to users on Windows 10, Windows 11, users with a single monitor, users with multiple monitors.

Windows Version (os.release())	CPU	GPU(s)	Number of displays	Display resolution(s)
10.0.19045	Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz	NVIDIA GeForce GTX 1060 6GB	1	1280x1024
10.0.22621	12th Gen Intel(R) Core(TM) i5-12600KF	NVIDIA GeForce RTX 3080	2	2560x1080, 1920x1080
10.0.19045	AMD Ryzen 5 5600X 6-Core Processor	NVIDIA GeForce RTX 3070	1	1920x1080
10.0.22621	Intel(R) Core(TM) i5-10400F CPU @ 2.90GHz	NVIDIA GeForce GTX 1650	1	1920x1080
10.0.19045	Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz	NVIDIA GeForce GTX 1080 Ti, Intel(R) UHD Graphics 630	1	1920x1080
10.0.22621	AMD Ryzen 5 5600G with Radeon Graphics	NVIDIA GeForce RTX 3060	1	1920x1080
10.0.22621	AMD Ryzen 7 7700X 8-Core Processor	AMD Radeon(TM) Graphics	3	1920x1080, 2560x1440, 1080x1920
10.0.22631	12th Gen Intel(R) Core(TM) i5-12400	Intel(R) UHD Graphics 730	1	1920x1080
10.0.22631	Intel(R) Core(TM) i7-10700KF CPU @ 3.80GHz	NVIDIA GeForce RTX 3070	1	1920x1080

Other Info

• It appears to happen regardless of windows display scaling setting (happens at 100%)
• It appears to happen regardless of whether has an integrated GPU or not
• One user did reinstall Windows 10 after they ran into this on Windows 11, and it was fixed for them. So it seems to me that it is a software issue under certain circumstances that I haven't pinpointed yet.

[Galkon]

Someone in Discord said I need to provide a fiddle -- I'm not sure how helpful it is since I cannot reproduce it and neither can anyone on our team, but here is a fiddle: https://gist.github.com/Galkon/c5e195442696a324afa03d9c391e8893

For anyone on electron team, if you want me to test any potential fixes with affected users or want to work with them to get more info, I will happily assist in that. My Discord is @Galkon

[Galkon]

Update: Affected users have the issue resolved when hardware acceleration is disabled for the app. A less than ideal solution for our app, but doable on a per-user basis... Is this a chromium issue then? Not sure where to go from here 🤔

[nextep]

Hi, i am running into this on windows 10, even with hardware accel off and with dual screen setup. Happy to share and help debug this

npm version
{
vatrion_electron: '1.0.0',
npm: '10.2.4',
node: '20.9.0',
acorn: '8.10.0',
ada: '2.6.0',
ares: '1.19.1',
base64: '0.5.0',
brotli: '1.0.9',
cjs_module_lexer: '1.2.2',
cldr: '43.1',
icu: '73.2',
llhttp: '8.1.1',
modules: '115',
napi: '9',
nghttp2: '1.57.0',
nghttp3: '0.7.0',
ngtcp2: '0.8.1',
openssl: '3.0.10+quic',
simdutf: '3.2.17',
tz: '2023c',
undici: '5.26.3',
unicode: '15.0',
uv: '1.46.0',
uvwasi: '0.0.18',
v8: '11.3.244.8-node.16',
zlib: '1.2.13.1-motley'
}

Here's how set some of the properties and i tried a lot of ways to set the width and height to no avail.

function createOverlayWindow() {
overlayWindow = new BrowserWindow({
width: screen.getPrimaryDisplay().bounds.width,
height: screen.getPrimaryDisplay().bounds.height,
frame: false,
transparent: true,
alwaysOnTop: false,
webPreferences: {
nodeIntegration: false,
contextIsolation: true,
preload: path.join(__dirname, 'preload.js')
}
});

overlayWindow.loadFile(path.join(__dirname, '../overlay.html'));

overlayWindow.webContents.openDevTools();
overlayWindow.setFullScreen(true);

overlayWindow.on('closed', () => {
    overlayWindow = null;
});

}

app.disableHardwareAcceleration();
app.whenReady().then(createMainWindow);

[Galkon]

Update here;

Detection of Transparency Failures

I used the desktopCapturer API to capture a thumbnail of your display which has this window on it at the time of the window showing.

I added color detection for ff000000, ff202020 and ff222222, and if the thumbnail is 95% or more that color then it sends the thumbnail to us.

So far out of a very large sample size, around 5% of all Windows users on electron will experience transparency failure. The vast majority of them are a true black screen (ff000000) as described in the original post.

Troubleshooting

For affected users, we have seen varying success rates with different attempts at resolving it.

1. For some users, turning off hardware acceleration for the electron app + restarting it solves it. For many, it does not.
2. For some users, tweaking some settings in Nvidia control panel may resolve it.
3. For the rest of them, nothing appears to fix it.

For now, I am detecting this automatically and disabling the transparent window, but this means functionality of the app is disabled for 5% of our users, not ideal.

Unsure how to proceed with this open issue.

[Shelim]

Hello, I just happen to run into very same problem with different WinAPI application (my own actually, Rust based with OpenGL renderer). It happen on my PC, and after googling a lot I found this page, so I wish to to share some of my insights:

1. The problem disappear completely (transparency is preserved) if the window does not have focus at start - but it will reappear as soon as it is focused (resulting in opaque window) and stays opaque even if losing focus again (correction: losing focus again retriggers correct transparency)
2. Any form of redrawing anything, including RedrawWindow(NULL, ...) (this should redraw entire desktop) has utter no effect.
3. Any form of invalidation has utter no effect
4. My attempt to loop hide-and-show the entire resulted in heavy shuttering at desktop and I am unable to verify if this has any effect
5. Calling UpdateLayeredWindow() per frame (also with non-NULL args containing unchanged position or size) has utter no effect
6. Calling SetLayeredWindowAttributes per frame has also no effect
7. Setting width or height to anything but desktop size WILL result in preserving the transparency of layered window (workaround the issue)
8. AND: I observed a strange visual artifact. Setting width/height to desktop size hides taskbar (as desired), but setting to any other value - even 1 pixel apart - will keep the taskbar visible
9. This leads me to believe there is some setting regarding borderless fullscreen gaming, but I was unable to find actual one.
10. More info soon...

Platform: nVidia GeForce / Win 11 <- both up to date

[Galkon]

Thanks @Shelim for the insights. For #7 that hasn't been the case for affected users on our end. It did fix it for some users, but they are a minority.