This looks like a similar bug that used to (maybe still?) exists with Flash video not playing, where the display of the video only updates if the window is refreshed in some way (scrolling up and down, for example). STR: 1. Go to http://www.omnigroup.com/products/omnigraffle-ipad/videos/ 2. Click on one of the two videos on that page. 3. Overlay appears with the .mov file embedded in it. After a bit of time, you should start hearing audio, but no video. Scroll the window up and down and you should see the video repaint.
Due to plug-in idle event changes?
Yeah, I can confirm comment 0 on mac nightlies, whereas Safari displays fine. Any chance this is IPC fallout, Benjamin? I don't think we have a regression range, but judging from Neil's comment, it's been broken for a few months, at least.
This page (http://www.2xstream.co.uk/mediaexamples/quicktime/qtlowstream.html) has sample videos that also die in exciting ways - much flicker, terrible messiness when scrolling while the video plays. Jeff worries that this might be hard to fix. I worry that it looks pretty terrible. Apple's trailer site works fine, interestingly.
So this was likely filed when quicktime was broken from retained layers. We then mostly fixed it during the platform work week and then broke it again with accelerated layers.
I can't reproduce this on 10.5 in yesterday's nightly on the omnigroup or 2xstream URLs. Scrolling is slow, but I think that's expected. This could be IPC-only, I can't test that. jrmuizel, this was filed on mac, so I don't think accelerated layers is relevant, is it? johnathan, can you try flipping the IPC prefs and trying again? Also, are you using 32-bit or 64-bit?
I can't reproduce this either with the latest nightly - bsmedberg, what IPC change did you want me to try? For what it's worth - the quicktime plugin doesn't load under 64-bit, and I filed the original bug running a 32-bit build.
If you can't reproduce, let's just call this WFM, and somebody can reopen if necessary.
I can reproduce this on tonight's nightly. 32-bit. IPC enabled. I think Jeff has it reproducing as well? I'll try turning off IPC and report back.
Toggling dom.ipc.plugins.enabled to false and restarting doesn't change things - still no video.
Josh, can you take or reassign this?
Oh, and I see it now on the 2xstream URL: if you leave the page, it works, but when you start scrolling the plugin is green for a few seconds before it starts repainting (IPC off, 10.5)
The accelerated surface that quicktime creates when it's drawing seems to go away when the drawing fails. This seems to happen when the plugin is clipped at all.
So here's my best guess as what's going on here: QuickTime draws using a combination of at least two APIs (QuickDraw and a private hardware accelerated IOYUV api from IOQTComponents) - The player controls seem to be drawn unconditionally with QuickDraw - If the plugin is not clipped the video is drawn using IOYUV into a CGSSurface, this surface lives on top of our CGSSurface which explains why the video will show up - If the plugin is clipped than we switch to a software path. I'm not sure how this data is eventually supposed to get to the screen, but it doesn't use a CGSSurface which explains why it doesn't show up with GL turned on. I'm not really sure what are options are for fixing this. Perhaps it is possible to avoid painting over the areas that we expect quickdraw to paint to. However, it's not clear to me if QuickDraw and CoreGraphics end up painting to the same shared memory window.
Safari avoids these problems through a couple of strategies: 1. They seem to use the Cocoa version of the quicktime plugin (i.e there is a quicktime view in the NSView hierarchy. This version seems to drawing quite differently than the version we use. For example, it seems to always draw the video using CoreView/OpenGL instead of IOQTComponents regardless of the clip. 2. They seem to use a transparent CGSSurface on top the regular NSView for 3D drawing. With this approach it seems possible that QuickDraw content will just show through.
Can't we use the Core Animation drawing model to render Quicktime? That should be nice and fast with GL layers.
Oh, that's only for 10.6 and up I guess. How about we enable GL on Mac for 10.6 and up only?
(In reply to comment #16) > Oh, that's only for 10.6 and up I guess. > > How about we enable GL on Mac for 10.6 and up only? That's probably our best option at this point.
Jeff - I take it from the comments here that that disabling OpenGL compositing fixes this bug, or at least significantly improves the situation. Since you figured this out and would presumably be the one to change opengl's enabled state I'm going to reassign that bug to you.
If this bug morphs into "limit GL to 10.6 and up", then it needs to block on bug 622229.
I would like the team to reconsider blocking here. Presently, anyone using OSX 10.5.* and Firefox 4 will have problems viewing Quicktime videos. Best case they'll leave artifacts in the titlebar if scrolled, but worst (and common!) case is that playback will be audio only. This breaks http://apple.com/trailers which is a pretty common website.
We should definitely limit GL to 10.6 and up.
We could work around bug 622229 by leaving GL enabled on 10.5 on test machines.
Benjamin, this is a hard blocker; we can't ship without functioning QuickTime support for 10.5 users, I don't think.
Created attachment 504832 [details] [diff] [review] Disable opengl layers by default on 10.5
Comment on attachment 504832 [details] [diff] [review] Disable opengl layers by default on 10.5 This will actually disable it on all 32-bit builds, but that's ok, since 32-bit Firefox supports Quickdraw, and Quickdraw is incompatible with OpenGL.
Yeah, I think that's what we want: if you have a QD plugin on 10.6, we want the workaround to be that you can explicitly launch in 32-bit mode and it will work.
This has caused layout/reftests/bugs/579323-1.html to go perma orange on OSX. Joe and Jeff don't seem to be around. I'm afraid that I would have to back it out unless I can find them on IRC soon.
We haven't had any test coverage with acceleration disabled since it was enabled by default, and our 32bit OSX test boxes and running 10.5. We should make sure we are getting coverage on both configurations going forward so this doesn't happen again.
(In reply to comment #28) > We haven't had any test coverage with acceleration disabled since it was > enabled by default, and our 32bit OSX test boxes and running 10.5. The 10.6 boxes have been running without GL since it landed because of bug 622229. I don't know how much changed in the gfx backend between 10.5 and 10.6 to know if that's useful.
I have disabled the test. See bug 627560 which was filed to track down the failure.
Created attachment 505670 [details] [diff] [review] further bustage fix: include npapi.h so NP_NO_QUICKDRAW can be defined
Original push: http://hg.mozilla.org/mozilla-central/rev/71dbb7813572 First bustage fix: http://hg.mozilla.org/mozilla-central/rev/ac1ca66248e8 Second bustage fix: http://hg.mozilla.org/mozilla-central/rev/85906f493f63
Apologies, to everyone for the disaster of a landing this was.
I tried to reproduce the original problem on a 10.5 machine in the lab, but I wasn't able to. If anything, the about:support information regarding graphics changes for the OpenGl support bit, from 0/1 to 0/2 in the machine I tried. So maybe that machine's graphics card wasn't supported to begin with, and that's why I didn't see the problem. Fx4b10 on 10.6 still works fine.