583499 - OpenGL acceleration breaks QuickDraw plugins

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Neil Lee [:neilio]]

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.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Due to plug-in idle event changes?

Comment 2

[Johnathan Nightingale [:johnath]]

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.

Comment 3

[Johnathan Nightingale [:johnath]]

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.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 5

[Benjamin Smedberg]

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?

Comment 6

[Neil Lee [:neilio]]

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.

Comment 7

[Benjamin Smedberg]

If you can't reproduce, let's just call this WFM, and somebody can reopen if necessary.

Comment 8

[Johnathan Nightingale [:johnath]]

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.

Comment 9

[Johnathan Nightingale [:johnath]]

Toggling dom.ipc.plugins.enabled to false and restarting doesn't change things - still no video.

Comment 10

[Benjamin Smedberg]

Josh, can you take or reassign this?

Comment 11

[Benjamin Smedberg]

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)

Comment 12

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can't we use the Core Animation drawing model to render Quicktime? That should be nice and fast with GL layers.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Oh, that's only for 10.6 and up I guess.

How about we enable GL on Mac for 10.6 and up only?

Comment 17

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 18

[Josh Aas]

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.

Comment 19

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

If this bug morphs into "limit GL to 10.6 and up", then it needs to block on bug 622229.

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We should definitely limit GL to 10.6 and up.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We could work around bug 622229 by leaving GL enabled on 10.5 on test machines.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Benjamin, this is a hard blocker; we can't ship without functioning QuickTime support for 10.5 users, I don't think.

Comment 24

[Jeff Muizelaar [:jrmuizel]]

Attachment: Disable opengl layers by default on 10.5

Comment 25

[Joe Drew (not getting mail)]

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.

Comment 26

[Benjamin Smedberg]

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.

Comment 27

[(no longer active)]

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.

Comment 28

[Matt Woodrow (:mattwoodrow)]

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.

Comment 29

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(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.

Comment 30

[(no longer active)]

I have disabled the test.  See bug 627560 which was filed to track down the failure.

Comment 31

[Joe Drew (not getting mail)]

Attachment: further bustage fix: include npapi.h so NP_NO_QUICKDRAW can be defined

Comment 32

[Joe Drew (not getting mail)]

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

Comment 33

[Jeff Muizelaar [:jrmuizel]]

Apologies, to everyone for the disaster of a landing this was.

Comment 34

[juan becerra [:juanb]]

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.