559441 - don't run Flash 10.1 out of process if machine has an Intel GMA9XX GPU

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Josh Aas]

We have good information that Flash 10.1 will negotiate the Quickdraw drawing model on Mac OS X 10.6 on machines (Mac Minis) that have Intel GMA9XX graphics. Flash does this because Quickdraw in-process is the only drawing model that performs well enough on these machines.

Our OOPP implementation does not support Quickdraw. Chrome is also dealing with this problem AFAIK.

This patch should solve the problem but I don't have access to any of the machines in question so I can't test. We need to test with this setup:

Trunk (1.9.3) build, Mac Mini with GMA9XX graphics, Mac OS X 10.6, latest Flash 10.1 release.

Comment 1

[Josh Aas]

Attachment: fix v1.0

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Josh, could you please trigger a tryserver build with this patch? That would help a lot. thanks.

Comment 3

[Nomis101]

I have access to a Mac Mini with GMA 950 and Mac OS X 10.6.3. And its easy to install Flash 10.1 on it. What can I do to help?

Comment 4

[Josh Aas]

Thanks. Can you test Flash 10.1 out-of-process in a trunk build and let us know what happens? Try using sites like YouTube, Adobe.com, any other basic Flash content. First we need to confirm that Flash 10.1 fails to load, then if that goes as expected we need to confirm that the patch here fixes the problem.

I will kick off a try server build with the patch here soon.

Comment 5

[Nomis101]

Yes, I can test this. I assume with an i386 build, right?

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I have tested todays Minefield build with Flash v10.1.53.7 but I can't see any problems on my Mac Mini with a GMA950 graphics card. Sorry.

Comment 7

[Josh Aas]

Nomis - yes, i386.

Comment 8

[Josh Aas]

Attachment: detection test app v1.0

This zip file includes source code, compile instructions, and an i386 binary which uses the detection method in fix v1.0 to determine whether or not a machine has the GPU in question here.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

FYI: In my case the test application returned "YES".

Comment 10

[Nomis101]

OK, I've tested this on the Mac Mini. First with a normal i386 trunk build and after that with a patched version (build my own).
If have tested youtube.com and cs5launch.adobe.com
With the normal trunk build its not really possible to watch the videos. First a second jumping FF icon pops up in the dock (different bug) and the video is very stagnant. You have to push the play button every second to watch the video. And sometimes you only have audio with a still picture.
Its much better with the patched version. I don't see the second FF icon in the dock and the videos are OK. Only minor rendering glitches in the load indicator.

I've set dom.ipc.plugins.enabled to true for this tests.

Flash 10.1.53.7
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100415 Minefield/3.7a5pre

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Josh, I was wrong. I retested it again and now I also see those problems. When pausing and resuming a flash video or simply by seeking the video will stop playing while audio is still continued in the background. It doesn't happen with OOPC turned off for Flash. So once the try server build is up I can also test it.

Comment 12

[Josh Aas]

We have to be careful to make sure we're not seeing bug 558350, in which video frames stop for a different reason.

Comment 13

[Benoit Girard (:BenWa)]

I renamed bug 558350 because the summary was misleading. If you see white vertical/horizontal lines then you are running into bug 558350. Sometimes the rendering stops before the lines appear. On the new youtube layout you can resize the window such that flash is against the left edge.

Comment 14

[Stuart Morgan]

FYI, unless y'all have already landed handling for the as-yet-unproposed "CA compositing is supported" NPAPI query, the testing for this needs to happen on sites that use "direct" or "gpu" as the Flash wmode, because it will negotiate CG+Cocoa for "transparent" and "opaque" (which lots of things use, because they are the only modes where DHTML overlays will work).

An example URL to try would be:
http://www1.ndr.de/flash/mediathek/index.html

The expected (failure) behavior would be absolutely no video. If you can see any frames of video at all, it's not using QuickDraw.

Comment 15

[Nomis101]

Attachment: crash report for www1.ndr.de/flash/mediathek/index.html

(In reply to comment #8)
> This zip file includes source code, compile instructions, and an i386 binary
> which uses the detection method in fix v1.0 to determine whether or not a
> machine has the GPU in question here.

On my test system the response is "GMA9XX Graphics: YES".


(In reply to comment #14)
> An example URL to try would be:
> http://www1.ndr.de/flash/mediathek/index.html
> 
> The expected (failure) behavior would be absolutely no video. If you can see
> any frames of video at all, it's not using QuickDraw.

I've also tested with this URL and this results in a crash and the dialog "The Adobe Flash plugin has crashed. No report available. Reload the page to try again." And additional crashes on every reload.
I've attached the crash report.

Comment 16

[Stuart Morgan]

The crash in SetWindow suggests that the OOP plugin host code is defaulting to CG+Cocoa and proceeding under that assumption, rather than defaulting to QD+Carbon (which is what should happen in 32-bit) then checking to make sure the plugin has negotiated a supported set of models and gracefully tearing down the plugin if not.

Comment 17

[Josh Aas]

Attachment: fix v1.1

Comment 18

[Benoit Girard (:BenWa)]

Comment on attachment 440526 [details] [diff] [review]
fix v1.1

+        // kCGLRendererIDMatchingMask and kCGLRendererIntel900ID are only defined in the 10.6 SDK
+        if ((rendProp & 0x00FE7F00) == 0x00024000) {

I would like to see those values #define to make this line more readable.

We should also detect if a proper drawing model is negotiated under 32-bit as described by Morgan in comment #16. We should file a follow up bug for this.

Comment 19

[Benjamin Smedberg]

Comment on attachment 440526 [details] [diff] [review]
fix v1.1

I'm really not a competent reviewer for this code.

Comment 20

[Josh Aas]

Attachment: fix v1.2

Comment 21

[Josh Aas]

I filed bug 560934 about verifying that acceptable event and drawing models were negotiated.

Comment 22

[Josh Aas]

Attachment: fix v1.3

More minor cleanup.

Comment 23

[Josh Aas]

pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/ce2a65c73b9e

Comment 24

[David Illsley]

Just FYI (and whatever support article gets written about OOPP/Mac), my 2007 MacBook2,1 also seems to have an Intel GMA 950.