914437 - "ASSERTION: Texture initialization failed! -- error 0x506, Source 0, Source format 0, RGBA Compat 1" with corrupt video

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Jesse Ruderman]

Attachment: q37-a.html

1. mkdir -p ~/px/q37
2. Put the following in ~/px/q37/prefs.js
      user_pref("layers.force-active", true);
      user_pref("media.autoplay.enabled", false);
      user_pref("dom.disable_open_during_load", false);
3. firefox -profile ~/px/q37/ q37-a.html

Result: 80% of the time,

###!!! ASSERTION: Texture initialization failed! -- error 0x506, Source 0, Source format 0,  RGBA Compat 1: 'Error', file /Users/jruderman/trees/mozilla-central/gfx/layers/opengl/CompositorOGL.cpp, line 929

* Mac OS X 10.8.4
* MacBook Pro (15" from Early 2011)
* Integrated graphics is active (Intel HD Graphics 3000)

This is exactly the same error message as in bug 896054.

Comment 1

[Jesse Ruderman]

Attachment: stacks??

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

First time I tried this, I got a warning instead:
WARNING: Framebuffer not complete -- error 0x8219, aFBOTextureTarget 0x0, aRect.width 1230, aRect.height 960: file gfx/layers/opengl/CompositingRenderTargetOGL.cpp, line 40
Error 0x8219 is GL_FRAMEBUFFER_UNDEFINED
but I suppose that could be unrelated.

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

I also hit the other assert.  Actually, they're much easier to hit if you run the optimized build, because of timing, and put something else in place to "flag" the assert.

Comment 4

[Markus Stange [:mstange]]

Attachment: refuse-render-when-window-is-invisible

You were spot on in bug 896054 comment 42:

(In reply to Matt Woodrow (:mattwoodrow) from bug 896054 comment #42)
> One vague guess would be that we're opening a new window and trying to
> composite it before the native window is actually ready.

In the testcase in this bug, we try to composite before the window has been shown. I don't know what's supposed to prevent us from doing that... do you?
This patch feels like a workaround - we just return early instead of rendering while the window is still closed. Can this break anything? One thing I thought of is that this might cause us to ignore the composition request that we issue from viewWillDraw once the window actually is shown, but maybe the WindowOverlayChanged trick saves us here (I haven't checked).

Comment 5

[Markus Stange [:mstange]]

Comment on attachment 813123 [details] [diff] [review]
refuse-render-when-window-is-invisible

>diff --git a/widget/cocoa/nsChildView.mm b/widget/cocoa/nsChildView.mm

>-void
>+bool
> nsChildView::PreRender(LayerManager* aManager)
> {
>   nsAutoPtr<GLManager> manager(GLManager::CreateGLManager(aManager));
>   if (!manager) {
>-    return;
>+    return false;

This actually needs to return true, otherwise it breaks OMTC with basiclayers.

Comment 6

[Markus Stange [:mstange]]

Attachment: refuse-render-when-window-is-invisible

with comment 5 addressed

Comment 7

[Markus Stange [:mstange]]

Attachment: also-refuse-when-no-window

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Markus, can this land?

Comment 9

[Markus Stange [:mstange]]

Yes, sorry for the delay, it was blocked on bug 924771 but the test has now been disabled.

https://hg.mozilla.org/integration/mozilla-inbound/rev/03f9c4191bf0
https://hg.mozilla.org/integration/mozilla-inbound/rev/8952c5133a67

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/03f9c4191bf0
https://hg.mozilla.org/mozilla-central/rev/8952c5133a67

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Can you please request approval for whatever needs landing on 26 please?