Closed Bug 1645223 Opened 5 years ago Closed 5 years ago

Context menu and menu toolbar hover effect is delayed by one frame if XRender, WebRender and GPU process are enabled

Categories

(Core :: Graphics: WebRender, defect)

Desktop
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla80
Tracking Status
firefox80 --- verified

People

(Reporter: jan, Assigned: nical)

References

(Blocks 1 open bug)

Details

(Keywords: nightly-community)

Attachments

(2 files)

Attached video 2020-06-12_00-24-30.mp4

Some users manually enabled Xrender for using X11 over the network (thin clients), even though proper remote desktop might perform better or be the more secure solution.

Problem: When users manually enable gfx.xrender.enabled while the GPU process is enabled due to WebRender qualification, they automatically see the behavior of bug 1567791, but for the menu toolbar and the context menu.
At the moment, they can either disable XRender, the gpu process or WebRender to fix it.

This problem is not present with Basic compositor and gfx.xrender.enabled.
(If you set layers.gpu-process.allow-software to true, it can be reproduced with all popups.)

This problem is present if WebRender is enabled, but still using Basic for small widgets - within the GPU process:
Since bug 1574746 upgraded various popups from Basic to WebRender, only the menu toolbar (press Alt key) and the context menu seem to be left affected.

When it comes to enabling WebRender by default on X11, what should happen?
Does it make sense to use WebRender with Xrender at all?
Should users who want to keep Xrender need to change a pref?
Could enabling WebRender by default for these thin clients have the same behavior as disabling Xrender (bug 1263222 comment 1)? Might these users even want to disable WebRender?
Have you any indication how many users have enabled Xrender?

There are multiple options, some are for example:
a) don't enable the GPU process if gfx.xrender.enabled is true on Linux: Wayland and Mac don't have a GPU process either, but the GPU process might be desired to reduce risks when shipping. This would disable it even for users who don't need Xrender.
b) enable Xrender only if gfx.xrender.enabled is true and layers.gpu-process.enabled is false: This would require users who really want to keep Xrender to change a pref. And later, they might get WebRender enabled by default and either keep it without GPU process or might even want to disable WebRender(?).
c) disable Xrender if WebRender is used with GPU process: Make Xrender respect layers.gpu-process.allow-software.
d) WebRender-everything (bug 1622633)
e) use WebRender even for small popups if gfx.xrender.enabled is true
f) fix this disabled edge case even though there are other Linux issues that want to be addressed.

Xrender is considered deprecated (bug 1180942) and there was an old question on whether to keep support at all (bug 1263222 comment 1).
That was my source of information.

(:Gijs (he/him) from bug 1644836 comment 12)

If it's deprecated, shouldn't we migrate people away from said deprecated configuration, or just stop honouring the xrender pref?

(Martin Stránský [:stransky] from bug 1644610 comment 8)

To be fair I think it could work if the XRender is enabled and X11 pixmaps are used. But that's very buggy scenario as it highly depends on X driver implementation and the code path is disabled by default. We use XShm for Basic compositor on X11 now.

Flagging Andrew for his Linux expertise. S4, since it's about a deprecated option (XRender).

Severity: -- → S4
Flags: needinfo?(aosmond)

I'm loathe to remove it if people are using for specific use cases. I think the correct course of action is to block WebRender. For some reason I thought we already were...

Blocks: wr-linux
Flags: needinfo?(aosmond)
Assignee: nobody → nical.bugzilla
Pushed by nsilva@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0537bd3deb10 Disable WebRender if XRender is enabled. r=aosmond
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla80
Flags: qe-verify+

Reproduced the issue with Firefox 79.0a1 (20200611093454) on Ubuntu 18.04.
The issue is no longer reproducible with Firefox 80.0RC1 (20200817172600) on Ubuntu 18.04. Also after enabling gfx.xrender.enabled pref to true Basic string is shown instead of WebRender in about:support, Compositing section.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: