Closed Bug 1742358 Opened 6 months ago Closed 5 months ago

[Linux] Firefox window is transparent / flashing right after browser start

Categories

(Core :: Widget: Gtk, defect)

defect

Tracking

()

RESOLVED FIXED
97 Branch
Tracking Status
firefox97 --- fixed

People

(Reporter: stransky, Assigned: emilio, NeedInfo)

References

Details

Attachments

(1 file)

Before we paint UI/web content the Firefox window is empty and transparent so you see desktop background. Firefox on Windows use a placeholder screen which is replaced by actual Firefox content when we're loaded.

I wonder if we can use such placeholder on Linux too.

The placeholder on Window look like a normal Firefox window but has empty area for web content and bold gray line instead of URL.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #0)

Before we paint UI/web content the Firefox window is empty and transparent so you see desktop background. Firefox on Windows use a placeholder screen which is replaced by actual Firefox content when we're loaded.

We used to at least paint a blank window (using about:blank). Do you know why that is not working, ie why is it transparent rather than white/black? Is that a regression? Does it happen with/without webrender and/or wayland?

I wonder if we can use such placeholder on Linux too.

This part feels like a separate enhancement. It should be a smaller lift to fix the transparency, at least.

Flags: needinfo?(stransky)
See Also: → 1665451

We can postpone window show at widget level or set the transparency later and show just blank window. The problem is that widget code does not know when the window has a valid content - can this be obtained somehow?

Flags: needinfo?(stransky) → needinfo?(gijskruitbosch+bugs)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #4)

We can postpone window show at widget level or set the transparency later and show just blank window. The problem is that widget code does not know when the window has a valid content - can this be obtained somehow?

I'm not sure what you mean by "valid content" in this context, or why we're showing a window before we've loaded DOM content for it that we can present (assuming that's what "valid content" means?). Even if we do though, I would have thought we could at least paint the default window background colour, which comes from the gtk theming prefs anyway, right? But I'm guessing :dthayer and/or :emilio can give you better answers here.

Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(emilio)
Flags: needinfo?(dothayer)

Yes, I think default background would be sufficient here. It's visible in debug build - we show Firefox window (which is transparent by default) but it takes another 2-3 seconds until some content is painted.

hm, it may be handled on widget level - we know that the window is painted to on compositor widget level.

Something like this mostly works, except for the fact that it breaks
rounded corners because we still clear with the opaque color behind
them.

Sorry for the lag. The patch above seems to work except for the issue hinted in the comment. We might be able to set the clear color to transparent after we've painted the chrome document. The issue is what's the best way to detect it.

Assignee: nobody → emilio
Attachment #9257548 - Attachment description: WIP: Bug 1742358 - WIP: Set default clear color to window background on expose. → Bug 1742358 - Set default clear color to widget window background on expose, and reset it on first contentful paint. r=jrmuizel!,stransky!
Status: NEW → ASSIGNED

removing that call or making that call pass false worked on wayland but not x11 (and still didn't show the rounded corners properly), so I went ahead with my initial solution, it wasn't a lot of work.

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7e3cdb88790d
Set default clear color to widget window background on expose, and reset it on first contentful paint. r=jrmuizel,stransky
Pushed by emilio@crisal.io:
https://hg.mozilla.org/integration/autoland/rev/c4d886e0717a
Use non-blank paint rather than contentful paint to fix test_drawWindow_widget_layers.html, which relies on transparent clear.
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
Component: General → Widget: Gtk
Product: Firefox → Core

Did we do any talos checks on this? I'm guessing this is going to move paint / window opening numbers, though I have no idea in which direction...

Flags: needinfo?(emilio)

I didn't, but I don't know why it would have any measurable effect on performance?

It doesn't really change how much paint work is done, just with which color does WR do the clear (so at most two more IPC messages with just one uint32_t each).

Flags: needinfo?(emilio)

I mean, conceptually the OS compositor could optimize something with the opaque clear color, so it could be faster, but it's hard to imagine how would it get that information without us telling it.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #16)

I didn't, but I don't know why it would have any measurable effect on performance?

Ah, sorry, I think I got confused wrt the idea of postponing one of the calls (comment #4 / comment #10), but I guess that's not the fix we went with.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #17)

I mean, conceptually the OS compositor could optimize something with the opaque clear color, so it could be faster, but it's hard to imagine how would it get that information without us telling it.

Just for the record:
Current hardware architectures don't allow fast checks on color opaqueness which is why on both Wayland and X11/EWMH there exists the concept of opaque-regions - a compositor hint that the area/region can be optimized. We did already set that hint before this patch, leading to small glitches if the background behind Firefox changed while the window still appeared transparent (I saw that a lot when launching a fresh debug build from terminal, as the terminal prints lots of stuff). So no, no performance differences expected from the compositor side (but the patch fixes an actual bug from the compositors point of view).

Regressions: 1749291
You need to log in before you can comment on or make changes to this bug.