Created attachment 451747 [details]
Using a debug build on Mac OS X 10.6:
###!!! ASSERTION: FBO not supported: 'Error', file /Users/jruderman/mozilla-central/gfx/src/thebes/utils/nsCoreAnimationSupport.mm, line 541
###!!! ASSERTION: nsCARenderer::Render failure: 'Not Reached', file /Users/jruderman/mozilla-central/layout/generic/nsObjectFrame.cpp, line 3671
Created attachment 451752 [details]
gdb output (includes stacks for the assertions)
This is plugins, I believe -- don't think we use CA for anything other than OOPP in the browser.
Yup, it's a problem with the 'Core Animation' drawing model for plug-ins.
Jesse can you include your Graphic Card information?
QuickTime Plug-in 7.6.6
NVIDIA GeForce 9400
Created attachment 451780 [details]
detailed graphics card info
I looked into the problem further and assumed that TEXTURE_RECTANGLE was not supported. From what I gather from the CGLTexImageIOSurface2D requires the use of TEXTURE_RECTANGLE so we might have no choice but to use it for IOSurface.
Jesse can you see if you have "OpenGL Driver Monitor" installed. Select 'Monitors', "Renderer Info" from the menu bar. Select 'Save As Text' and attach it? I'm interested in seeing what support is provided TEXTURE_RECTANGLE.
Created attachment 452870 [details]
output from OpenGL Driver Monitor
Here you go, BenWa. (I clicked "Expand All" before clicking "Save As Text".)
It just occurred to me that the Quicktime's object frame had a width of 20,000. Core Animation, or at least the CARenderer, doesn't even support anything this large:
-[<OOPMovieLayer: 0x2f57b00> display]: Ignoring bogus layer size (20000.000000, 150.000000)
Chromium has the same error.
roc thinks that we should just render nothing, which I agree with, which is the behavior I currently get. The only problem is that the code keeps trying to initialize and this is draining the CPU so I will post a patch for this.
If someone thinks the expect behavior should be otherwise let me know.
Created attachment 461952 [details] [diff] [review]
Prevent Setup if size is unsupported
This patch prevents the caller from trying to initialize the nsCARenderer again if we know that this size is unsupported.
Checked the patch for bit-rot, still working. Checkin-needed.
How can this be verified? Can you please provide some STR.