631004 - [Mac] Poor CoreAnimation (Flash) performance without GL Layers

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Benoit Girard (:BenWa)]

The fix for bug 591687 will only address the performance regression when GL Layers is enabled. We need to investigate our options for the case where GL Layers is disabled (such as certain video cards).

Here are some options off the top of my head that I don't necessarily advocate:

bug 629602 is a possible solution but at best will still suffer performance regression if the plug-in view is partly covered. I'm still not 100% if it will even work at all.

Implement bug 629602 without doing the readback when the view is partly covered. This will led to bad behavior and roc doesn't like this idea. I noticed that chrome does this on my machine for example.

Disable Core Animations for those configurations. This could mean that we have to run certain plug-ins in-process using white/blacklisting.

Comment 1

[Benjamin Smedberg]

We should disable CA if we can. That does mean that we need Flash to support a CoreGraphics/Cocoa events combination, which is currently iffy.

I don't remember from the email thread whether we ever answered the question about whether we could have a special layer type for CALayer even when we aren't using GL layers, so that we can paint the CALayer as part of our non-accelerated rendering stack.

Async rendering would also help improve Firefox responsiveness in this case (because we could do the readback in the plugin process and not block Firefox on it), although it will still leave dropped frames and poor performance.

Comment 2

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

(In reply to comment #1)
> I don't remember from the email thread whether we ever answered the question
> about whether we could have a special layer type for CALayer even when we
> aren't using GL layers, so that we can paint the CALayer as part of our
> non-accelerated rendering stack.

How would we paint that CALayer? Using readback? That sounds like what we do now.

Comment 3

[Benjamin Smedberg]

I don't know mac graphics APIs, but I was hoping that there was a method which would render a CALayer to the screen as part of the normal painting sequence without having to read it back.

Comment 4

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

I remember that we tried to find a way to do that and we couldn't get it to work with Quicktime.

Comment 5

[Josh Aas]

Can someone remind me why Core Graphics would be faster than Invalidating Core Animation without GL layers?

How many graphics cards have we blacklisted from OpenGL compositing? What percentage of our users will have this problem?

I don't really know what Flash will do if we claim not to support CA in some situations. I assume it would fall back to CG but we should test.

Comment 6

[Matt Woodrow (:mattwoodrow)]

With Core Animation we are rendering to a GL-backed IOSurface, and reading the data back into system memory is really hurting us on some systems.

Comment 7

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

To be even clearer: in many or most cases, rendering with GL and then reading back into system memory is slower than just rendering into system memory with the CPU.

Comment 8

[Benoit Girard (:BenWa)]

(In reply to comment #5)
> I don't really know what Flash will do if we claim not to support CA in some
> situations. I assume it would fall back to CG but we should test.

I just tested this (flipped the CoreAnimation support flags in PluginInstanceChild). Flash did use CoreGraphics out of process happily for a youtube 1080p trailer. The composition performance was much faster on our end, but Flash ran so much slower internally rendering with Core Graphics (Shark samples) that it negated all performance benefits and ran much slower.

Comment 9

[Benoit Girard (:BenWa)]

I think this is at the very least a final hard blocker, at least for my machine.

Comment 10

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

Can someone produce a testcase so we can see what is meant by "poor" performance? It's hard to reason about this bug otherwise.

Worse than 3.6?
Unusuable?

Also, what segment of the Mac market do we expect to be affected?

Comment 11

[Benoit Girard (:BenWa)]

I used the following to test:

First make sure you're not using GL Layers:
1) Go to about:support and confirm that you get 'GPU Accelerated Windows 0/1'

2) Go to a 1080p youtube trailer such as the following:
http://www.youtube.com/watch?v=_i2RCBa3l-g

Performance during buffering is unusable. Performance after buffering is worse then 3.6. I will post real statistics tonight.

Comment 12

[Johnathan Nightingale [:johnath]]

Judging from comment 11, this is a meaningful regression from 3.6 - roc/bsmedberg? Is this a beta hardblocker? Final?

Comment 13

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

This only affects Flash OOP unaccelerated, which should be a very small number of our users - don't think we'll block on the issue.

Renominate if drivers got that logic wrong.

Comment 14

[Bogdan Maris, Desktop Test Engineering]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0

On latest Nightly (buildID: 20130808030205) while buffering 1080p videos, the browser is usable, performance is in normal parameters.