OMTC Linux: Chrome CSS can disable hardware acceleration.

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
3 years ago
3 years ago

People

(Reporter: mike.bean.heyns, Assigned: acomminos)

Tracking

39 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted])

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
Created attachment 8643492 [details]
Screencast of problem.

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150703091230

Steps to reproduce:

I'm not sure if this is a known bug or expected behaviour. Reporting anyway.

1) Launch Firefox with env variable MOZ_USE_OMTC=1
2) Override the following css:
    #main-window[sizemode="normal"][htitlemode="always"] {
        -moz-appearance: none !important;
        background: transparent !important;
        border-radius: 7px 7px 0px 0px;
    }



Actual results:

Hardware acceleration/OMTC gets disabled.


Expected results:

Hardware acceleration/OMTC should stay enabled.

Updated

3 years ago
Component: Untriaged → Graphics
Product: Firefox → Core
(Reporter)

Updated

3 years ago
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Giving the main window rounded corners disables OMTC, is this expected?
Flags: needinfo?(matt.woodrow)
Adding rounded corners will make the window mode transparent I guess, and we explicitly disable acceleration/OMTC in that case [1].

I'm not sure why though, it doesn't seem like we'd need to.

Andrew might be interested in seeing if we really need this.


[1] http://mxr.mozilla.org/mozilla-central/source/widget/gtk/nsWindow.cpp#6408
Flags: needinfo?(matt.woodrow) → needinfo?(acomminos)
Whiteboard: [gfx-noted]
(Assignee)

Comment 3

3 years ago
I can take this, we probably should be handing RGBA windows anyway when we have a compositing window manager.
Assignee: nobody → acomminos
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(acomminos)
Whiteboard: [gfx-noted]
(Assignee)

Updated

3 years ago
Depends on: 630346
See Also: → bug 630346
(Assignee)

Comment 4

3 years ago
I think the best we can do for this bug would be to use the OpenGL compositor for all cases except where the window is transparent and we don't have a compositing window manager. As mentioned in bug 630346, there's little point to performing readback to use the SHAPE extension for the non-compositing WM case.
(Assignee)

Comment 5

3 years ago
Created attachment 8648896 [details] [diff] [review]
Handle composition change events on GTK to update widget transparency, always create RGBA visuals.

This patch makes GTK windows always use RGBA visuals and listens to GTK's compositing-changed event, implementing support for windows which change transparency at runtime. It only falls back to the basic compositor if we don't have a compositor or an RGBA visual for the window (i.e. when we have to use XShape).

Thanks!
Attachment #8648896 - Flags: review?(karlt)
Comment on attachment 8648896 [details] [diff] [review]
Handle composition change events on GTK to update widget transparency, always create RGBA visuals.

Is there actually a need to support translucency on the main windows?

This would come at a cost because the compositor then needs to consider lower windows.  We at least shouldn't switch to ARGB visuals until UpdateOpaqueRegion() is implemented, with gdk_window_set_opaque_region I guess, but I'd like to have a good reason to support this.
Flags: needinfo?(andrew)
Attachment #8648896 - Flags: review?(karlt)
(Assignee)

Comment 7

3 years ago
> Is there actually a need to support translucency on the main windows?

Mainly allowing custom user styles and GTK themes to provide transparent widgets. I agree that we should implement gdk_window_set_opaque_region though if we do choose to ship this.

Anyway, it's not terribly important, especially if the cost for WM composition is high; I'm okay with this sitting here until a good use case is found.
Flags: needinfo?(andrew)
(Reporter)

Comment 8

3 years ago
I don't know if this is related to the same issue. When overriding the above css in nightly, e10s windows go blank.
Andrew, is this something we still want to support?
Flags: needinfo?(andrew)
Whiteboard: [gfx-noted]
(Assignee)

Comment 10

3 years ago
It's quite a rare use case- I don't see this as particularly critical to support. The performance cost of always using an ARGB GLX visual for our windows is likely more important, as Karl mentioned.
Flags: needinfo?(andrew)
(In reply to Andrew Comminos [:acomminos] from comment #10)
> It's quite a rare use case- I don't see this as particularly critical to
> support. The performance cost of always using an ARGB GLX visual for our
> windows is likely more important, as Karl mentioned.

Thanks Andrew. Given this I suspect we can at least unassign you from this bug. Question is, should we keep this bug open or just close it? We can always reopen if we choose to revisit the issue sometime down the road.
(Assignee)

Comment 12

3 years ago
Let's close it for now, at least until a situation arises where we really need an ARGB visual.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.