Why does a white background appear when Lapce or Floem Application is launched, and how can it be eliminated?

[moon989]

As shown in the above image, there is a white background that appears upon startup; it's very unsightly and affects the visual experience. It is recommended to eliminate it.

[timboudreau]

You may want to note what OS + version plus version of floem you are running, as how unused parts of windows are painted can be platform-dependent.

I've noticed (I'm not an author of floem, just have contributed a few patches), that the WindowView that is the root view (a container for whatever content the app developer supplies) for all windows is opaque - with one of my patches, you can set window transparency on Mac OS, but the root view being opaque prevents that from working correctly.

So there probably is something to address here regarding how the root view is styled. I believe the white you are seeing is the default theme, which is dark-on-light - probably whatever you put in the window has a fixed size, so that part is white and the rest is whatever the OS paints underneath as the window background in non-transparent mode (Mac OS dark them I'm guessing?)

[moon989]

@timboudreau Thank you for your reply； The following is environment information。

• OS： Win11；
• floem : V0.1.1;

Running Lapce （All release version ） also results in a white background appearing, as shown in the image.

[timboudreau]

I'm not going to have any ideas about Windows - too many years working at Sun Microsystems where installing Windows was a firing offense...

I spent some time this afternoon attempting and failing to get transparent windows actually working on Mac OS, and ran into similar issues - there's something that really wants to paint the windows white or black (if transparent) that's below the level where Floem does anything (it does pass the transparent flag through to winit - I verified that).

Some googling showed up a set of flags passed to MacOS by winit via wgpu that determine whether the window has an alpha channel at all. Might be an avenue to look at here as well.

Though it may simply be that you need to style your bottommost view with fill_width() and fill_height() and you're just getting the root view (container Floem puts your views in in the window) background because your component doesn't fully cover it.

Try that, in fact.

[jrmoulton]

@timboudreau

specifically for getting transparent windows it has to do with the alpha mode here. Different setting affect different platforms in different ways.
https://github.com/lapce/floem/blob/1674b0476c4a857322877f765bc8489c0d61d01b/vger/src/lib.rs#L88C9-L97C11

I don't understand everything about those settings but I have previously used them to get a transparent window

[timboudreau]

Good to know. I can try to get it happy on Mac OS and Linux/X11 (maybe even Wayland if I want to futz with rebuilding it with different flags - I'm on a circa 2016 Broadwell CPU with a somewhat buggy GPU there). But I have no recourse for testing on Windows.

[Long0x0]

I debugged winit on Windows and found the same problem, just after the window is created.

According to MS docs, we need to set window's background in register_window_class or process the WM_ERASEBKGND message.

https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-wndclassa

[moon989]

How can I solve this problem? Is there anyone who can provide suitable suggestions?

[jrmoulton]

@moon989 the default background color (the clear color) is set by the renderer

floem/vger/src/lib.rs

Line 573 in 02205d8

let desc = wgpu::RenderPassDescriptor {

There is probably a way to add a color to the window config and get it passed down to this point

[panekj]

There is probably a way to add a color to the window config and get it passed down to this point

It's already transparent, there is no need to pass anything

[jrmoulton]

It's already transparent, there is no need to pass anything

But that's the issue. We don't always want it to be transparent.

Setting this clear color to a specific value will make the window clear to that color when initializing (I think).

[panekj]

We don't always want it to be transparent.

We do, otherwise you will get either different colours between the app itself and what you provide in View.
I specifically made that change so it doesn't require any colour configuration.

[panekj]

I'm pretty sure the issues with white window flash at the start are related to the backend used and/or transparency mode used.
In particular transparency behaves weirdly between modes and Auto is not handling all cases.
3b1cb03

[moon989]

This bug is also exist in Lapce all versions Release .

[panekj]

Lapce uses Floem, so all issues in Floem will be present in Lapce

[timboudreau]

FWIW, on Mac OS with a transparent window background set and the flag for a transparent window set when creating the window, you get a window with a black background.

So I think something is amiss with window initialization, though it may or may not be related to this issue on Windows. I've tried patching it a few different ways but have not found a fix yet.

In researching it, I ran across a comment on a bug report for something using winit saying that winit's implementation of NSView was missing some properties introduced more recently or trying to use properties that are no longer used. I don't know the accuracy of that but it might be a thing you check for solving window background issues Mac OS.

[moon989]

This bug also exist in the latest version of lapce . I'm trying to build an application on Windows using floem, but this problem, if not resolved, is very user-unfriendly to user.

[moon989]

It's not a bug ?

[dzhou121]

It's not a bug ?

It is a bug, but we haven't figured out how to fix it yet.

[Long0x0]

Finally fixed this on winit: Long0x0/winit@23722ea. The window will remain transparent until drawn by floem. Could you check if this works?

[moon989]

Finally fixed this on winit: Long0x0/winit@23722ea. The window will remain transparent until drawn by floem. Could you check if this works?

@Long0x0

Great, this has fixed the issue, and I've tested it on Windows 11. Hope it gets merged into the main branch soon.