Closed Bug 914437 Opened 11 years ago Closed 11 years ago

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

Categories

(Core :: Graphics: Layers, defect)

x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla27
Tracking Status
firefox26 --- affected
firefox27 --- fixed

People

(Reporter: jruderman, Assigned: mstange)

References

Details

(Keywords: assertion, testcase, Whiteboard: [qa-])

Attachments

(4 files, 1 obsolete file)

Attached file q37-a.html (deleted) —
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.
Attached file stacks?? (deleted) —
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.
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.
Attached patch refuse-render-when-window-is-invisible (obsolete) (deleted) — Splinter Review
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).
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Attachment #813123 - Flags: review?(matt.woodrow)
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.
Attachment #813123 - Flags: review?(matt.woodrow) → review+
with comment 5 addressed
Attachment #813123 - Attachment is obsolete: true
Attached patch also-refuse-when-no-window (deleted) — Splinter Review
Attachment #813644 - Flags: review?(matt.woodrow)
Attachment #813644 - Flags: review?(matt.woodrow) → review+
Markus, can this land?
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Blocks: 896054
No longer depends on: 896054
Blocks: 899478
Can you please request approval for whatever needs landing on 26 please?
Whiteboard: [qa-]
Depends on: 942913
Blocks: 899044
Blocks: 921323
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: