1191184 - OMTC Linux: Chrome CSS can disable hardware acceleration.

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Michael Heyns]

Attachment: 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.

Comment 1

[Timothy Nikkel (:tnikkel)]

Giving the main window rounded corners disables OMTC, is this expected?

Comment 2

[Matt Woodrow (:mattwoodrow)]

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

Comment 3

[Andrew Comminos [:acomminos]]

I can take this, we probably should be handing RGBA windows anyway when we have a compositing window manager.

Comment 4

[Andrew Comminos [:acomminos]]

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.

Comment 5

[Andrew Comminos [:acomminos]]

Attachment: 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!

Comment 6

[Karl Tomlinson (: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.

Comment 7

[Andrew Comminos [:acomminos]]

> 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.

Comment 8

[Michael Heyns]

I don't know if this is related to the same issue. When overriding the above css in nightly, e10s windows go blank.

Comment 9

[u279076]

Andrew, is this something we still want to support?

Comment 10

[Andrew Comminos [:acomminos]]

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.

Comment 11

[u279076]

(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.

Comment 12

[Andrew Comminos [:acomminos]]

Let's close it for now, at least until a situation arises where we really need an ARGB visual.