Closed Bug 559441 Opened 10 years ago Closed 10 years ago

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

Categories

(Core :: Plug-ins, defect)

All
macOS
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: jaas, Assigned: jaas)

Details

Attachments

(3 files, 3 obsolete files)

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.
Attached patch fix v1.0 (obsolete) — Splinter Review
Josh, could you please trigger a tryserver build with this patch? That would help a lot. thanks.
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?
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.
Yes, I can test this. I assume with an i386 build, right?
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.
Nomis - yes, i386.
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.
FYI: In my case the test application returned "YES".
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
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.
We have to be careful to make sure we're not seeing bug 558350, in which video frames stop for a different reason.
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.
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.
(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.
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.
Attachment #439097 - Flags: review?(bgirard)
Attached patch fix v1.1 (obsolete) — Splinter Review
Attachment #439097 - Attachment is obsolete: true
Attachment #440526 - Flags: review?(bgirard)
Attachment #439097 - Flags: review?(bgirard)
Attachment #440526 - Flags: review?(benjamin)
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.
Attachment #440526 - Flags: review?(bgirard) → review+
Comment on attachment 440526 [details] [diff] [review]
fix v1.1

I'm really not a competent reviewer for this code.
Attachment #440526 - Flags: review?(benjamin)
Attached patch fix v1.2 (obsolete) — Splinter Review
Attachment #440526 - Attachment is obsolete: true
I filed bug 560934 about verifying that acceptable event and drawing models were negotiated.
Attached patch fix v1.3Splinter Review
More minor cleanup.
Attachment #440582 - Attachment is obsolete: true
pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/ce2a65c73b9e
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Just FYI (and whatever support article gets written about OOPP/Mac), my 2007 MacBook2,1 also seems to have an Intel GMA 950.
You need to log in before you can comment on or make changes to this bug.