Closed Bug 1418212 Opened 7 years ago Closed 6 years ago

Opening the profiler with WR enabled causes WR to get disabled unless extensions.webextensions.remote is true

Categories

(Core :: Graphics: WebRender, defect, P5)

Unspecified
Linux
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox57 --- unaffected

People

(Reporter: emilio, Unassigned)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(1 file)

I experience this consistently when I try to take a WR profile, so I need to enable that other pref.

That other pref has its own set of problems though, including various errors from WR spawned in stderr.

Anyway.

STR:

 * Enable webrender.
 * Install the Gecko profiler.
 * Press the profiler wheel to start / stop profiling.
 * As soon as the popup opens, current tab goes blank and WR gets disabled.
 * On stderr:

[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: Compositors might be mixed (5,2)

Expected results:

 * I'm able to profile with WR enabled and no random webextension prefs.

FWIW, also happens with the hamburger menu, though I haven't checked if the pref fixes that, will check that now.
> FWIW, also happens with the hamburger menu, though I haven't checked if the
> pref fixes that, will check that now.

The hamburger menu isn't fixed by that...

FWIW, the problems with the pref that I was talking about was extra black padding around the profiler popup, and errors like:

  ERROR:webrender::frame: ERROR: Invalid window dimensions! Please call api.set_window_size()

On stderr.
:emilio, in which OS did you experience it?
Flags: needinfo?(emilio)
Whiteboard: [gfx-noted]
Whiteboard: [gfx-noted] → [wr-mvp] [triage] [gfx-noted]
Linux, WebRender - OpenGL version new 4.5 (Core Profile) Mesa 17.4.0-devel
Flags: needinfo?(emilio)
OS: Unspecified → Linux
Whiteboard: [wr-mvp] [triage] [gfx-noted] → [gfx-noted]
So I tracked this down to us wanting to create a window with windowAttrs.depth == 32, but ChooseFBConfigs only returning depths == 24.

I don't know where does the window come from and if we can control the requested depth, that's the next task I guess :)

Meanwhile I found some cleanup to do, will do that in bug 1420170.
(In reply to Emilio Cobos Álvarez [:emilio] from comment #0)
> [GFX1-]: Failed GL context creation for WebRender: 0
> [GFX1-]: Compositors might be mixed (5,2)

bug 1401455 has the same error message. (Proprietary Nvidia driver: Buggy background until you click on the burger button and get a fallback to OpenGL(?) compositing.)

---

(Sotaro Ikeda [:sotaro] from bug 1419023 comment 3)
> I suspect that Bug 1418212 is caused by GLX and widget related problem.
The first two error messages are the same you are getting.

GPU Process(!) + OOP Webextensions prevent WebRender from functioning at all (on Linux).
bug 1406230 [@ gfxPlatform::Init | mozilla::widget::WindowSurfaceX11::GetVisualFormat ]
> Error	Compositors might be mixed (5,2)
> GP+[GFX1-]: Failed GL context creation for WebRender: 0
> GP+[GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT
> GP+[GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #7)
> The first two error messages are the same you are getting.
> 
> GPU Process(!) + OOP Webextensions prevent WebRender from functioning at all
> (on Linux).
> bug 1406230 [@ gfxPlatform::Init |
> mozilla::widget::WindowSurfaceX11::GetVisualFormat ]
> > Error	Compositors might be mixed (5,2)
> > GP+[GFX1-]: Failed GL context creation for WebRender: 0
> > GP+[GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT
> > GP+[GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT

Yeah, I investigated this a bit today. It seems that the window is requesting a 32-bit depth buffer, and mesa cannot find a suitable FBConfig, failing to create the GLContext.

As a note to self, Markus pointed out that these nsWindows are created from nsMenuPopupFrame, and that the options that probably make this happen are the transparency mode or `aInitData->mSupportsTransparency` in https://searchfox.org/mozilla-central/rev/477ac066b565ae0eb3519875581a62dfb1430e98/widget/gtk/nsWindow.cpp#3661
This happens to fix the issue, and nothing looks broken because, I guess, the hamburger menu and such don't use transparency at all...

I wonder which widgets do use it... If none, the easiest fix is just removing that functionality I guess...

Otherwise, I guess we need to figure out why mesa doesn't return any suitable configuration for that (maybe it just doesn't exist with my gpu).
Depends on: 1423407
I would like to understand why this breaks with WebRender on + force acceleration but not with Webrender off + force acceleration. Or does it?
With WebRender off + force acceleration, do we create a BasicCompositor or a CompositorOGL for these panels?
(In reply to Markus Stange [:mstange] from comment #10)
> I would like to understand why this breaks with WebRender on + force
> acceleration but not with Webrender off + force acceleration. Or does it?
> With WebRender off + force acceleration, do we create a BasicCompositor or a
> CompositorOGL for these panels?

It creates a CompositorOGL, we take this path[1] instead of the one above it because we're not using WR.

[1]: https://searchfox.org/mozilla-central/rev/f5f1c3f294f89cfd242c3af9eb2c40d19d5e04e7/gfx/gl/GLContextProviderGLX.cpp#947
I cannot repro this anymore.
can this be resolved fixed by bug 1357487 ?
Flags: needinfo?(emilio)
Presumably even sooner given comment 12.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(emilio)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: