Last Comment Bug 692759 - [OOPP] Firefox 8.0 not rendering Core-Animation-based plugins (like QuickTime) in 64-bit mode
: [OOPP] Firefox 8.0 not rendering Core-Animation-based plugins (like QuickTime...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: 8 Branch
: x86 Mac OS X
: -- major with 2 votes (vote)
: mozilla10
Assigned To: Benoit Girard (:BenWa)
:
Mentors:
https://bugs.webkit.org/show_bug.cgi?...
: 695226 (view as bug list)
Depends on: 695243
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-07 05:32 PDT by Vishvesh
Modified: 2012-01-18 07:09 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+


Attachments
Freezed frame image. This is the only frame the browser shows (47.92 KB, image/jpeg)
2011-10-07 05:32 PDT, Vishvesh
no flags Details
Logging patch (not a fix) (10.25 KB, patch)
2011-10-12 10:43 PDT, Steven Michaud [:smichaud] (Retired)
no flags Details | Diff | Splinter Review
TimerFix (13.53 KB, patch)
2011-10-14 11:01 PDT, Benoit Girard (:BenWa)
smichaud: review+
Details | Diff | Splinter Review
Hardware info of the mac machine on which the build didn't render the animation (19.00 KB, application/octet-stream)
2011-10-19 06:48 PDT, Vishvesh
no flags Details
List of Macintosh Hardware on which build is working (22.50 KB, application/octet-stream)
2011-10-19 07:19 PDT, Vishvesh
no flags Details
Don't use async plugin for CoreAnimation (Non ICA) (7.06 KB, patch)
2011-10-19 11:44 PDT, Benoit Girard (:BenWa)
no flags Details | Diff | Splinter Review

Description Vishvesh 2011-10-07 05:32:02 PDT
Created attachment 565506 [details]
Freezed frame image. This is the only frame the browser shows

User Agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.6.8; U; en) Presto/2.9.168 Version/11.51

Steps to reproduce:

1. Built NetscapeCoreAnimationPlugin provided by webkit community
2. Placed the plug-in "~/Library/Internet Plug-Ins"
3. Opened the test page provided with the plug-in.

NetscapeCoreAnimationPlugin can be checked out from: 
http://svn.webkit.org/repository/webkit/trunk/Examples/NetscapeCoreAnimationPlugin


Actual results:

Plug-in was displayed but the animation wasn't rendered. It displayed a single frame. Everything else seems to be working fine. The plug-in was detecting mouse clicks but the rendering had frozen.


Expected results:

It should have rendered the animation.
Comment 1 Steven Michaud [:smichaud] (Retired) 2011-10-07 09:10:59 PDT
You need to add the following lines to the top of
NetscapeCoreAnimationPlugin's main.m for it to be able to compile (at
least on OS X 10.6.8):

typedef int16_t int16
typedef int32_t int32

By default NetscapeCoreAnimationPlugin compiles as a 32-bit binary
(not a 64-bit binary).  But this bug happens whether or not this
plugin runs as a 32-bit binary or a 64-bit binary.

It only happens when the plugin is run out of process (when the
browser runs in 64-bit mode).  The bug doesn't happen when the browser
runs in 32-bit mode (when the plugin runs in process).

Here's the regression range:

firefox-2011-07-13-03-07-41-mozilla-central
firefox-2011-07-14-03-07-48-mozilla-central

It's not obvious (at least to me) which patch in this range could have
triggered the bug, so I'm going to do an hg bisect to find out.

By the way, this bug also effects the QuickTime plugin, so it's quite
a bit more important than it might appear to be on the surface.
Comment 2 Benoit Girard (:BenWa) 2011-10-07 09:55:42 PDT
This is intended behavior. This example plugin does not use the proper drawing model for gecko. The only difference is that Gecko expects an InvalidateRect event to be notified that the plugin needs to be repainted:
https://wiki.mozilla.org/NPAPI:InvalidatingCoreAnimation
Comment 3 Steven Michaud [:smichaud] (Retired) 2011-10-07 10:11:11 PDT
Benoit, how would you revise the NetscapeCoreAnimationPlugin to fix this problem?

Someone should open a WebKit bug on this.
Comment 4 Steven Michaud [:smichaud] (Retired) 2011-10-07 10:13:38 PDT
Finally, if this problem isn't fixed soon in the QuickTime plugin, we'll need to include some kind of QuickTime-specific workaround (to allow it to continue to use "improper" methods).
Comment 5 Steven Michaud [:smichaud] (Retired) 2011-10-07 10:30:10 PDT
Josh, do you have any contacts in Apple you can talk to about this bug?

If not, maybe we should just bring it up on the plugin-futures mailing list.
Comment 6 Steven Michaud [:smichaud] (Retired) 2011-10-07 10:40:52 PDT
Benoit, when was Core Animation support "turned on"?

Do you know which patch triggered this bug?  I don't see anything Core-Animation-specific (or even Mac-specific) among the patches landed during the regression range.
Comment 7 Steven Michaud [:smichaud] (Retired) 2011-10-07 10:43:19 PDT
> Do you know which patch triggered this bug?  I don't see anything
> Core-Animation-specific (or even Mac-specific) among the patches
> landed during the regression range.

Oops, sorry.  I wasn't looking carefully enough at the mozilla-inbound
merges.

Here's the patch that turned on Core Animation:

Bug 663259 - Enable Mac Async plugin by default. r=cjones,mattwoodrow
author     Benoit Girard <b56girard@gmail.com>
           Tue Jul 12 10:31:18 2011 -0400 (at Tue Jul 12 10:31:18 2011 -0400)
changeset 72713    5cea57e451dd
parent 72712       2d5bc18fdf9c
child 72714        ce95693001bc
pushlog:           5cea57e451dd
Comment 8 Benoit Girard (:BenWa) 2011-10-07 11:05:02 PDT
Ohh I never noticed that Quicktime was affected by this. We should be able to land a patch to refresh at 60 FPS, however our hope was to remove support for vanilla CoreAnimation without the CoreAnimationInvalidate extension we proposed in 2010. Contacting Apple to fix Quicktime for this would be ideal.
Comment 9 Steven Michaud [:smichaud] (Retired) 2011-10-07 11:10:34 PDT
Benoit,	in bug 663259 comment #39 you talk about "special casing",
with the possible implication that the QuickTime plugin behaves
differently when it thinks it's running in a Firefox release.

Is this what you meant?

If so, do you know what the QuickTime plugin does differently?  Does
it possibly fall back to not using Core Animation?

By the way, I tried to fool QuickTime into thinking it was running in
a Firefox release by changing a current nightly's user agent string to
match that of FF 7.0.1.  This had no discernable effect on QuickTime's
behavior -- this bug still happened.

(By the way, I've been testing with movie trailers at
http://www.apple.com/trailers, particularly
http://trailers.apple.com/trailers/independent/beingelmo/.  Note that,
because of bug 687610 and bug 670036, you need to clear the network
cache before running every test.)
Comment 10 Steven Michaud [:smichaud] (Retired) 2011-10-07 11:13:51 PDT
(In reply to comment #8)

> Ohh I never noticed that Quicktime was affected by this. We should
> be able to land a patch to refresh at 60 FPS, however our hope was
> to remove support for vanilla CoreAnimation without the
> CoreAnimationInvalidate extension we proposed in 2010.

Maybe we could do this as a QuickTime-specific "quirk".

> Contacting Apple to fix Quicktime for this would be ideal.

Let's hope Josh can do this ... or has already done so :-)
Comment 11 Benoit Girard (:BenWa) 2011-10-07 11:26:42 PDT
(In reply to Steven Michaud from comment #9)
> Benoit,	in bug 663259 comment #39 you talk about "special casing",
> with the possible implication that the QuickTime plugin behaves
> differently when it thinks it's running in a Firefox release.
> 
> Is this what you meant?
> 
> If so, do you know what the QuickTime plugin does differently?  Does
> it possibly fall back to not using Core Animation?
> 
> By the way, I tried to fool QuickTime into thinking it was running in
> a Firefox release by changing a current nightly's user agent string to
> match that of FF 7.0.1.  This had no discernable effect on QuickTime's
> behavior -- this bug still happened.
> 
> (By the way, I've been testing with movie trailers at
> http://www.apple.com/trailers, particularly
> http://trailers.apple.com/trailers/independent/beingelmo/.  Note that,
> because of bug 687610 and bug 670036, you need to clear the network
> cache before running every test.)

Ohh right! I forgot that this happens. We do have significant changes with the async changes so we should be careful in assuming that this will work on the release version without good proof.

(In reply to Steven Michaud from comment #10)
> Maybe we could do this as a QuickTime-specific "quirk".

A quirk would probably be the best way, I want to limit the number of plugins that depend on a invalidate timer. If plugins don't want to care about invalidation they can setup their own refresh timer at whatever rate they care about.
Comment 12 Benjamin Smedberg [:bsmedberg] 2011-10-07 12:17:23 PDT
If this is the quirk we need for quicktime we should make it a click-to-play plugin: the timer solution is absoutely terrible for power usage/battery life, especially after you've reached the "end" of a movie and there are no more actual changes being made.
Comment 13 Steven Michaud [:smichaud] (Retired) 2011-10-07 13:00:48 PDT
Is there a way to only use the timer when we "need" it (while a movie is playing)?
Comment 14 Steven Michaud [:smichaud] (Retired) 2011-10-07 21:43:05 PDT
Actually, it might be easiest just to refuse to use Core Animation with the QuickTime plugin (and make this the quirk).  We could (presumably) fall back to using Core Graphics.
Comment 15 Shiv 2011-10-07 23:49:16 PDT
Additional note:

Plugins using CAOpenGLLayer and CVDisplay Link to update the layer is also failing on FF8. The same works fine with FF7, FF6 and webkit based browsers.

Should the plugin raise InvalidateRect event even while using CVDisplay Link to update ?
OR 
Is this a bug with FF8 ?
Comment 16 Marcia Knous [:marcia - use ni] 2011-10-10 13:04:42 PDT
Nominating for tracking as I was contacted by Sling Media - they indicated that this affects their product and they believe it will affect many others as well.
Comment 17 christian 2011-10-10 13:07:35 PDT
(In reply to Steven Michaud from comment #14)
> Actually, it might be easiest just to refuse to use Core Animation with the
> QuickTime plugin (and make this the quirk).  We could (presumably) fall back
> to using Core Graphics.

Would this be a simple pref flip? Or is the blacklist in code?
Comment 18 Steven Michaud [:smichaud] (Retired) 2011-10-10 13:13:45 PDT
> Would this be a simple pref flip? Or is the blacklist in code?

I was thinking we could add a QuickTime-specific quirk to do this.

But a quirk (or quirks) would only work with QuickTime,	or with	a very
short list of majorly popular plugins.

Plugin vendors need to be made aware that this is a problem that
should be fixed on their end, as per comment #2.
Comment 19 Benoit Girard (:BenWa) 2011-10-10 13:15:08 PDT
(In reply to Christian Legnitto [:LegNeato] from comment #17)
> (In reply to Steven Michaud from comment #14)
> > Actually, it might be easiest just to refuse to use Core Animation with the
> > QuickTime plugin (and make this the quirk).  We could (presumably) fall back
> > to using Core Graphics.
> 
> Would this be a simple pref flip? Or is the blacklist in code?

If we do it only for OOPP only then we have to change this from true to false:
http://mxr.mozilla.org/mozilla-central/source/dom/plugins/ipc/PluginInstanceChild.cpp#417
Comment 20 Benjamin Smedberg [:bsmedberg] 2011-10-10 13:17:43 PDT
I thought we removed all mention of the non-invalidating CoreAnimation support because we got Flash to support the invalidating one in the FF4 timeframe. Why can't we remove it from both the in-process and out-of-process impls?
Comment 21 Steven Michaud [:smichaud] (Retired) 2011-10-10 13:19:59 PDT
> Plugin vendors need to be made aware that this is a problem that
> should be fixed on their end, as per comment #2.

However, we could probably have done a better job of announcing the
change that triggered this bug, and how to work around it.

Maybe we should consider whitelisting plugins that we know can do Core
Animation properly (by our lights), and falling back to something else
(Core Graphics?) for every plugin not on the whitelist.
Comment 22 Benjamin Smedberg [:bsmedberg] 2011-10-10 13:33:09 PDT
Which plugins are those? QuickTime doesn't use invalidting CA, right, so we wouldn't want to whitelist it?
Comment 23 Steven Michaud [:smichaud] (Retired) 2011-10-10 13:47:30 PDT
>> Maybe we should consider whitelisting plugins that we know can do
>> Core Animation properly (by our lights)
>
> Which plugins are those?

I don't know.  Possibly only Flash. 

> QuickTime doesn't use invalidating CA, right, so we wouldn't want to
> whitelist it?

Correct.
Comment 24 srichard@slingmedia.com 2011-10-11 10:06:07 PDT
Has a bug already been open for Webkit? If so what is the #?

(In reply to Steven Michaud from comment #3)
> Benoit, how would you revise the NetscapeCoreAnimationPlugin to fix this
> problem?
> 
> Someone should open a WebKit bug on this.
Comment 25 Benoit Girard (:BenWa) 2011-10-11 10:50:34 PDT
Filed here:
https://bugs.webkit.org/show_bug.cgi?id=69852
Comment 26 Steven Michaud [:smichaud] (Retired) 2011-10-11 10:55:22 PDT
> Maybe we should consider whitelisting plugins that we know can do
> Core Animation properly (by our lights), and falling back to
> something else (Core Graphics?) for every plugin not on the
> whitelist.

I just realized that using a whitelist has a severe drawback -- if
your plugin isn't on the list, how will you test implementing
"correct" support for Invalidating Core Animation?

So we probably can't use a whitelist.

How about if we	only support Core Animation (of any kind) for those
plugins that explicitly request support for Invalidating Core
Animation?
Comment 27 Benoit Girard (:BenWa) 2011-10-11 11:37:30 PDT
I think whitelist-ing for CoreAnimation would be perfectly acceptable. This would mean that other plugins would have to use InvalidatingCoreAnimation which is our supported drawing model. We should start to deprecate CoreAnimation drawing model since we don't want to support this going forward.
Comment 28 Steven Michaud [:smichaud] (Retired) 2011-10-11 11:45:54 PDT
Whitelisting for plugins that explicitly request *Core Animation* would be alright.

Whitelisting for plugins that explicitly request *Invalidating Core Animation* wouldn't be -- for the reason I gave in comment #26.
Comment 29 Benoit Girard (:BenWa) 2011-10-11 12:05:29 PDT
Actually since we want Quicktime to default to Core Graphics (or preferably ICA) then there is no reason to whitelist plugins to use CoreAnimation. I filed a new bug 693727 to investigate removing the drawing model completely.
Comment 30 Steven Michaud [:smichaud] (Retired) 2011-10-11 12:12:39 PDT
The problem with adding a quirk to make QuickTime use Core Graphics is:

What do we do about the other plugins whose vendors are only now learning that they need to use Invalidating Core Animation with the next Firefox release (and not the non-invalidating Core Animation that they were expecting to be able to use).
Comment 31 Benoit Girard (:BenWa) 2011-10-11 12:14:54 PDT
Let's continue that discussion in bug 693727. I'm open to having a deprecation plan if required.
Comment 32 Steven Michaud [:smichaud] (Retired) 2011-10-11 12:27:47 PDT
The discussion is also directly relevant here.

We need to choose among the following ways to fix this bug (or something like them):

1) Add a quirk to force QuickTime to use Core Graphics, because it can't do Invalidating Core Animation.

2) Force all plugins that explicitly request Core Animation (but not Invalidating Core Animation) to use Core Graphics.

3) Force some plugins (like QuickTime) that explicitly request Core Animation to use Core Graphics.  This would be something like a blacklist.

In this I assume that we can't support non-invalidating Core Animation, because of the performance penalty.  The alternatives would change if we found ways to alleviate the performance penalty.
Comment 33 Benoit Girard (:BenWa) 2011-10-11 12:34:26 PDT
All these 3 solutions all have in common that we force quicktime to use Core Graphics. We need to make sure that it will correctly use Core Graphics when Core Animation is not available. I'm waiting for my try build to finish to confirm this.
Comment 34 Steven Michaud [:smichaud] (Retired) 2011-10-11 12:45:27 PDT
> We need to make sure that it (QuickTime) will correctly use Core
> Graphics when Core Animation is not available.

Yes indeed.

I've assumed that QuickTime used Core Graphics before your patch for
bug 663259 landed (which turned on Core Animation, or at least made it
the default).  Is this true?
Comment 35 Benoit Girard (:BenWa) 2011-10-11 12:47:57 PDT
(In reply to Steven Michaud from comment #34)
> I've assumed that QuickTime used Core Graphics before your patch for
> bug 663259 landed (which turned on Core Animation, or at least made it
> the default).  Is this true?

I think it might of used QuickDraw.
Comment 36 Steven Michaud [:smichaud] (Retired) 2011-10-11 12:53:47 PDT
> I think it might of used QuickDraw.

I vaguely remember something about QuickDraw not working in OOPP plugins.

Josh?
Comment 37 Benoit Girard (:BenWa) 2011-10-11 12:58:26 PDT
QuickDraw was never supported for OOPP because the drawing model was not designed to be remoted easily.

This was the reason we had to white-list plugins we would allow to run in 32-bit OOP mode to Flash+Java since in 32-bit mode it is perfectly valid to not request a drawing model and expect Quickdraw.
Comment 38 Steven Michaud [:smichaud] (Retired) 2011-10-11 13:02:35 PDT
Thanks for the info.  Note that even before Core Animation was turned on/made the default, using QuickTime didn't force a restart in 32-bit mode.

I'm going to write a test patch that logs which drawing modes plugins claim to support, and which drawing mode we end up using.
Comment 39 Benoit Girard (:BenWa) 2011-10-11 17:45:03 PDT
So even the current version of Quicktime doesn't support ICA or CG. With my patch we detect that Quicktime request a proper drawing models and we get the dialog to restart in 32-bit mode.

We should request Quicktime to support ICA. In the mean time our options are to either fix the timers to work correctly or to require the 32-bit restart. I think the first is the best user experience.
Comment 40 Steven Michaud [:smichaud] (Retired) 2011-10-12 10:09:50 PDT
I tested with my logging patch, backported to the patch just before
the patch for bug 663259 landed (the one that broke our support for
CoreAnimation, as opposed to Invalidating CoreAnimation).  This shows
that QuickTime used CoreAnimation with Firefox even before that patch
landed -- not CoreGraphics, and not QuickDraw.  Sorry for the
confusion :-(

And I've confirmed what Benoit says:  If you stop the QuickTime plugin
from using CoreAnimation it falls back to using QuickDraw.  Something
we want to avoid, if at all possible.

I also discovered that this bug goes away if you change
plugins.use_layers from its (post bug 663259) default value of true to
false.  Is this a viable solution?  Could we do this for all plugins
that request CoreAnimation (as opposed to Invalidating CoreAnimation)?
Do we need the timer if plugins.use_layers is false?

(Note that, because of bug 687610, you need to clear your network
cache before testing QuickTime media.)
Comment 41 Steven Michaud [:smichaud] (Retired) 2011-10-12 10:17:43 PDT
With my logging patch I've found out that Flash explicitly requests (and uses) Invalidating CoreAnimation.  So we wouldn't need to turn off plugins.use_layers for Flash.
Comment 42 Steven Michaud [:smichaud] (Retired) 2011-10-12 10:43:49 PDT
Created attachment 566584 [details] [diff] [review]
Logging patch (not a fix)

By the way, here's my logging patch.  A tryserver build should be available by (I hope) the end of the day.
Comment 43 Steven Michaud [:smichaud] (Retired) 2011-10-12 14:35:30 PDT
Here's a tryserver build of my logging patch:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-6859ddd1b171/try-macosx64/firefox-10.0a1.en-US.mac.dmg
Comment 44 Vishvesh 2011-10-12 23:33:58 PDT
I think Firefox should support both CoreAnimation and Invalidating CoreAnimation plug-in for some more time. This would provide time for the plug-in makers to make changes on their end.
Comment 45 Steven Michaud [:smichaud] (Retired) 2011-10-13 10:51:58 PDT
Benoit, please answer my questions from comment #40.
Comment 46 Benoit Girard (:BenWa) 2011-10-13 12:21:56 PDT
Sorry Steven, I've been traveling.

(In reply to Steven Michaud from comment #40)
> I also discovered that this bug goes away if you change
> plugins.use_layers from its (post bug 663259) default value of true to
> false.  Is this a viable solution?  Could we do this for all plugins
> that request CoreAnimation (as opposed to Invalidating CoreAnimation)?
> Do we need the timer if plugins.use_layers is false?

It would be possible to do that but I feel like it's not the right solution. Presumably the invalidate events are not working. I can take a look tomorrow.
Comment 47 Steven Michaud [:smichaud] (Retired) 2011-10-13 12:50:39 PDT
> Sorry Steven, I've been traveling.

No problem.  Just didn't want this to fall through the cracks.

> It would be possible to do that but I feel like it's not the right
> solution. Presumably the invalidate events are not working. I can
> take a look tomorrow.

Thanks.  

Maybe we could fall back to my solution (turning off
plugins.use_layers for plugins that request CoreAnimation, but not
Invalidating CoreAnimation) if we can't find a better one in time.  It
does have the advantage of being simple.

And time is a problem.  I really think we should get this fixed in FF
8.
Comment 48 christian 2011-10-13 13:00:59 PDT
FYI if there isn't a resolution here we will probably back out bug 663259. Please let me know if there are large issues with doing so.
Comment 49 Benoit Girard (:BenWa) 2011-10-13 13:08:49 PDT
I had a bit of time to look at it before the next lecture.

With Pre-async plug-in the browser would drive the invalidate/redrawing so I built the invalidate timer in the parent process to save some IPCs call.

With async plug-in the invalidate event has to start from the plugin process. The CA Timer quirk doesn't do this.

I'll write a patch for this tomorrow. We should still prepare a deprecation plan for CA in bug 693727.
Comment 50 Steven Michaud [:smichaud] (Retired) 2011-10-13 13:18:05 PDT
> We should still prepare a deprecation plan for CA in bug 693727.

Yes!! :-)
Comment 51 Benoit Girard (:BenWa) 2011-10-14 11:01:51 PDT
Created attachment 567136 [details] [diff] [review]
TimerFix
Comment 52 Steven Michaud [:smichaud] (Retired) 2011-10-14 12:16:37 PDT
Comment on attachment 567136 [details] [diff] [review]
TimerFix

Benoit, please tell us more about this patch. 

It looks like you've moved the timer from the browser process to the
plugin process, and turn it on only for plugins that use CoreAnimation
(though not Invalidating CoreAnimation).

What are the consequences of this?  I expect there will be less of a
performance hit running the timer in the plugin process, but have you
tried to measure how much?

It looks like we were already using the browser process timer for
CoreAnimation plugins (aside from Flash).  Then why did we have this
bug?

You haven't made any attempt to make the timer only run when plugin
media is playing.  Is it because this would be too difficult?  Is it
because you don't think it's necessary?

I haven't yet tested this patch, but I will in the next hour or so.
Comment 53 Shiv 2011-10-14 12:36:17 PDT
(In reply to Steven Michaud from comment #43)
> Here's a tryserver build of my logging patch:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-
> 6859ddd1b171/try-macosx64/firefox-10.0a1.en-US.mac.dmg

I tried this build, with the webkit sample plugin (http://svn.webkit.org/repository/webkit/trunk/Examples/NetscapeCoreAnimationPlugin), the animation renders fine (with plugins.use_layers set to false).

My plugin uses CAOpenGLLayer and Core Video Display Link to update the layer. Browser fails to render Animations (older versions of FF (v4, v5, v6) and Webkit browsers work fine).

I used QCCompositionLayer in my plugin just to test. It renders the animation fine.

CAOpenGLLayer and Core Video Display Link fail to render. Any ideas on this ?
Comment 54 Benoit Girard (:BenWa) 2011-10-14 12:45:19 PDT
I explained the problem in Comment 49.

(In reply to Steven Michaud from comment #52)
> Comment on attachment 567136 [details] [diff] [review] [diff] [details] [review]
> TimerFix
> 
> Benoit, please tell us more about this patch. 
> 
> It looks like you've moved the timer from the browser process to the
> plugin process, and turn it on only for plugins that use CoreAnimation
> (though not Invalidating CoreAnimation).
> 

Right, With CoreAnimation we have no way of knowing when we need to repaint thus we've always assumed that we should paint at 50 FPS. We proposed InvalidatingCoreAnimation to solve this.

> What are the consequences of this?  I expect there will be less of a
> performance hit running the timer in the plugin process, but have you
> tried to measure how much?
> 

The performance implication of moving the timer from the parent to the child should be negligible when running without GL layers. We will be making 50 more IPC calls/sec then we would without this patch. With GL layers we're not doing any extra IPC calls.  
 
> It looks like we were already using the browser process timer for
> CoreAnimation plugins (aside from Flash).  Then why did we have this
> bug?
> 
We are only using the process timer for plugins that don't support InvalidatingCoreAnimation which the only plugins I'm aware of is Quicktime.

> You haven't made any attempt to make the timer only run when plugin
> media is playing.  Is it because this would be too difficult?  Is it
> because you don't think it's necessary?
> 
This is because we don't have any way of knowing when media is/isn't playing. InvalidatingCoreAnimation solves this, thus we should do outreach to get Quicktime to support ICA.
Comment 55 Steven Michaud [:smichaud] (Retired) 2011-10-14 12:48:40 PDT
(In reply to comment #53)

My patch from comment #42 is a logging patch, for debugging purposes.
As I already said, it *isn't* a fix, and doesn't change current
behavior.

> I tried this build, with the webkit sample plugin
> (http://svn.webkit.org/repository/webkit/trunk/Examples/NetscapeCoreAnimationPlugin),
> the animation renders fine (with plugins.use_layers set to false).

So setting plugins.use_layers to false makes the
NetscapeCoreAnimationPlugin example work correctly in current versions
of Firefox.  This confirms my own results.  Good.

> My plugin uses CAOpenGLLayer and Core Video Display Link to update
> the layer. Browser fails to render Animations (older versions of FF
> (v4, v5, v6) and Webkit browsers work fine).
>
> I used QCCompositionLayer in my plugin just to test. It renders the
> animation fine.
>
> CAOpenGLLayer and Core Video Display Link fail to render. Any ideas
> on this ?

Is all this with plugins.use_layers set to 'false', or with it left at
its default value of 'true'?
Comment 56 Steven Michaud [:smichaud] (Retired) 2011-10-14 12:51:39 PDT
(In reply to comment #54)

Thanks for the info.  But you didn't answer one of my questions.

>> It looks like we were already using the browser process timer for
>> CoreAnimation plugins (aside from Flash).  Then why did we have
>> this bug?
>
> We are only using the process timer for plugins that don't support
> InvalidatingCoreAnimation which the only plugins I'm aware of is
> Quicktime.

Then why does QuickTime have this bug in current code?
Comment 57 Steven Michaud [:smichaud] (Retired) 2011-10-14 14:10:33 PDT
I've now talked to Benoit on IRC, and have a better understanding of
this bug ... or so I hope.  Benoit, please tell me if there's
something wrong with any of the following:

1) The timer in the browser process hasn't worked properly since we
   started drawing plugins asynchronously (since the patch for bug
   663259 landed).  This is why it didn't help with QuickTime.

2) Asynchronous plugin drawing is turned on by setting
   plugins.use_layers to 'true', and turned off by setting it to
   'false'.

3) Using a 50 fps timer with asynchronous plugin drawing doesn't
   increase the number of IPC calls, and so should have no effect on
   performance.

Given all this (and assuming I haven't misunderstood), is it
worthwhile only using the timer (in the plugin process) if
plugins.use_layers is 'true' (and if layers.acceleration is also
turned on)?
Comment 58 Steven Michaud [:smichaud] (Retired) 2011-10-14 15:07:53 PDT
Comment on attachment 567136 [details] [diff] [review]
TimerFix

I can't see anything wrong with this patch, but I think you should
consider my suggestion from comment #57 (that you ensure the
plugin-side timer is only used when layers.acceleration is turned on
and plugins.use_layers is true).

I tested on both OS X 10.6.8 and 10.7.2.  I had no problems on 10.6.8.
And though I did have a significant problem on 10.7.2, it was only
with the NetscapeCoreAnimationPlugin example, and not with QuickTime.

This patch may need revision.  But I think we should land it as	is, as
quickly as possible, so that interested plugin vendors can test with
it.  Shiv and srichard@slingmedia.com, this particularly means you :-)
But we'd also like to get tests of any other plugins that support
CoreAnimation.

My problem on 10.7.2 was heavy flickering with the
NetscapeCoreAnimationPlugin example.  I've no idea why I only saw this
on Lion.  The problem went away	when I turned plugins.use_layers off.

I did some performance testing, but it was a comparison of apples and
oranges -- of a completely unoptimized patched build with an optimized
nightly.  Even this test showed only a moderate performance penalty.
But I need to retest with an optimized build of the patch.

Once again, note that, because of bug 687610, you need to clear your
network cache before each test of QuickTime media.
Comment 59 Steven Michaud [:smichaud] (Retired) 2011-10-14 16:37:40 PDT
Here are the results of my (very limited) performance tests:

I tested with a single QuickTime video (http://trailers.apple.com/trailers/independent/beingelmo/) on both OS X 10.6.8 and 10.7.2.  I compared performance with the patch to performance without the patch (in equivalent nightly code) with plugins.use_layers turned off.

On 10.6.8 I saw a 10%-15% performance loss in the plugin-container process, and about a 10% gain in the firefox-bin process.  On 10.7.2 I also saw the ~10% gain in the firefox-bin process, but I don't think I saw any performance loss in the plugin-container process.  This puzzles me.  It may simply have been because the CPU usage jumped up and down a lot more on 10.7.2 (both with and without the patch).

I measured performance running top after sshing in from another machine.
Comment 60 Steven Michaud [:smichaud] (Retired) 2011-10-14 16:48:10 PDT
I should mention that I tested on a very fast machine -- a few months old MacBook Pro.

The performance penalty of the patch in the plugin process would probably be higher on an old, slow machine.
Comment 61 Shiv 2011-10-14 21:58:07 PDT
(In reply to Steven Michaud from comment #55)
> (In reply to comment #53)
> 
> My patch from comment #42 is a logging patch, for debugging purposes.
> As I already said, it *isn't* a fix, and doesn't change current
> behavior.
> 
> > I tried this build, with the webkit sample plugin
> > (http://svn.webkit.org/repository/webkit/trunk/Examples/NetscapeCoreAnimationPlugin),
> > the animation renders fine (with plugins.use_layers set to false).
> 
> So setting plugins.use_layers to false makes the
> NetscapeCoreAnimationPlugin example work correctly in current versions
> of Firefox.  This confirms my own results.  Good.
> 
> > My plugin uses CAOpenGLLayer and Core Video Display Link to update
> > the layer. Browser fails to render Animations (older versions of FF
> > (v4, v5, v6) and Webkit browsers work fine).
> >
> > I used QCCompositionLayer in my plugin just to test. It renders the
> > animation fine.
> >
> > CAOpenGLLayer and Core Video Display Link fail to render. Any ideas
> > on this ?
> 
> Is all this with plugins.use_layers set to 'false', or with it left at
> its default value of 'true'?

All the test were performed with plugins.use_layers set to 'false'.
Comment 62 Vishvesh 2011-10-17 06:23:45 PDT
How can I check the build which fixed this issue? Can you please share the link to the build.
Comment 63 Vishvesh 2011-10-17 06:33:04 PDT
(In reply to Steven Michaud from comment #60)
> I should mention that I tested on a very fast machine -- a few months old
> MacBook Pro.
> 
> The performance penalty of the patch in the plugin process would probably be
> higher on an old, slow machine.

Can you share the build?
Comment 64 Steven Michaud [:smichaud] (Retired) 2011-10-17 07:00:05 PDT
(In reply to comment #62 and comment #63)

I'll do a tryserver build, and paste in the link here when it's done.  It should be available sometime this afternoon.

(The builds I tested with are my own custom builds.)
Comment 67 srichard@slingmedia.com 2011-10-17 11:33:33 PDT
Help me understand: Is this issue also going to be fixed in Firefox 8 & 9 after it has been verified in Firefox 10?
Comment 68 Steven Michaud [:smichaud] (Retired) 2011-10-17 11:45:16 PDT
It's my understanding that we're going to try to fix this for Firefox 8 and above.  The final decision hasn't been made, though.
Comment 69 Steven Michaud [:smichaud] (Retired) 2011-10-17 11:51:51 PDT
Here's a tryserver build made with Benoit's patch from comment #51:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-99fd8409a252/try-macosx64/firefox-10.0a1.en-US.mac.dmg

Please test with it!  On both OS X 10.6.8 and 10.7.2!

This patch will be landed on the "trunk" in the next day or two, and appear in subsequent mozilla-central nightlies.  But this hasn't happened yet.
Comment 70 Steven Michaud [:smichaud] (Retired) 2011-10-17 11:54:44 PDT
> This patch will be landed on the "trunk" in the next day or two, and
> appear in subsequent mozilla-central nightlies.  But this hasn't
> happened yet.

Oops, this is incorrect.  The patch has	*already* landed on the trunk,
and will appear in tomorrow's and subsequent mozilla-central
nightlies.  For	nightlies see
ftp://ftp.mozilla.org/pub/firefox/nightly/.
Comment 71 Vishvesh 2011-10-18 07:34:59 PDT
(In reply to Ehsan Akhgari [:ehsan] from comment #66)
> https://hg.mozilla.org/mozilla-central/rev/3c5e89543399

I see three issues in this 
1. In a plug-in using a Layer derived from CAOpenGLLayer and  using OpenGL textures for drawing, I see constant flicker. One frame is drawn and after that I see a white patch. No error messages are printed in the console.app

2. In case of NetscapeCoreAnimationPlugin the animation rendering is slower on the build compared to Safari and Google Chrome.

3. The browser no longer respects "asynchronous" property of CAOpenGLLayer. Irrespective of whether "asynchronous" is set to "YES" or "NO", the "drawInCGLContext:" and "canDrawInCGLContext:" callbacks occur.  "canDrawInCGLContext:" should be called only when asynchronous is set to true/YES.


So I will reopen the bug.
Comment 72 Vishvesh 2011-10-18 07:38:41 PDT
(In reply to Vishvesh from comment #71)
> (In reply to Ehsan Akhgari [:ehsan] from comment #66)
> > https://hg.mozilla.org/mozilla-central/rev/3c5e89543399
> 
> I see three issues in this 
> 1. In a plug-in using a Layer derived from CAOpenGLLayer and  using OpenGL
> textures for drawing, I see constant flicker. One frame is drawn and after
> that I see a white patch. No error messages are printed in the console.app
> 
> 2. In case of NetscapeCoreAnimationPlugin the animation rendering is slower
> on the build compared to Safari and Google Chrome.
> 
> 3. The browser no longer respects "asynchronous" property of CAOpenGLLayer.
> Irrespective of whether "asynchronous" is set to "YES" or "NO", the
> "drawInCGLContext:" and "canDrawInCGLContext:" callbacks occur. 
> "canDrawInCGLContext:" should be called only when asynchronous is set to
> true/YES.
> 
> 
> So I will reopen the bug.

With respect to, Issue 1 and 3. The plug-in works fine on Firefox 4.x,5.x,6.x,7.x, Safari 5.x and Google Chrome.
Comment 73 Benoit Girard (:BenWa) 2011-10-18 07:45:54 PDT
I have a few things in mind today that I will play with. Regarding #2 I don't think were concerned about the performance of CoreAnimation plugins. We're only concerned about plug-ins using the InvalidatingCoreAnimation model.
Comment 74 Steven Michaud [:smichaud] (Retired) 2011-10-18 08:12:11 PDT
*** Bug 695226 has been marked as a duplicate of this bug. ***
Comment 75 Vishvesh 2011-10-18 08:29:53 PDT
(In reply to Benoit Girard (:BenWa) from comment #73)
> I have a few things in mind today that I will play with. Regarding #2 I
> don't think were concerned about the performance of CoreAnimation plugins.
> We're only concerned about plug-ins using the InvalidatingCoreAnimation
> model.
I have a modified a plug-in to test issue number 3.
http://www.box.net/shared/6oemiidlxo2sh78qlzz0
In the file main.m, change  
"m_exampleCAOpenGLLayer.asynchronous = YES;" to "m_exampleCAOpenGLLayer.asynchronous = NO;"
Comment 76 Benoit Girard (:BenWa) 2011-10-18 09:45:09 PDT
I have a build that fixes problem 1) building on try. I'm not sure why this only happens with certain plugins.
Comment 77 Mozilla RelEng Bot 2011-10-18 16:11:04 PDT
Try run for fb9257a791fb is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=fb9257a791fb
Results (out of 2 total builds):
    success: 2
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-fb9257a791fb
Comment 78 Vishvesh 2011-10-18 20:20:21 PDT
(In reply to Benoit Girard (:BenWa) from comment #73)
> I have a few things in mind today that I will play with. Regarding #2 I
> don't think were concerned about the performance of CoreAnimation plugins.
> We're only concerned about plug-ins using the InvalidatingCoreAnimation
> model.

I was going through the timer patch. It looks to me that render performance(#2) can be improved by changing the FPS rate to 60. We need to consider this because current rendering is a little sluggish.

This line of code
#define DEFAULT_REFRESH_MS 20 // CoreAnimation: 50 FPS
Comment 79 Benoit Girard (:BenWa) 2011-10-18 20:28:10 PDT
Do you have any particular example of this in mind?
Comment 80 Vishvesh 2011-10-18 20:31:58 PDT
(In reply to Benoit Girard (:BenWa) from comment #76)
> I have a build that fixes problem 1) building on try. I'm not sure why this
> only happens with certain plugins.

Can you please share the build?
Comment 81 Vishvesh 2011-10-18 20:33:59 PDT
(In reply to Benoit Girard (:BenWa) from comment #79)
> Do you have any particular example of this in mind?

Is this regarding issue #2?
Comment 83 Vishvesh 2011-10-18 20:45:06 PDT
(In reply to Benoit Girard (:BenWa) from comment #82)
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.
> com-fb9257a791fb/try-macosx64/firefox-10.0a1.en-US.mac.dmg

Thanks. I will test it and get back with the results.
Comment 84 Vishvesh 2011-10-19 06:16:16 PDT
The results are mixed. On some macintosh machine the build is working fine and in some others the plug-in is not rendering. I tested it with this plug-in http://www.box.net/shared/6oemiidlxo2sh78qlzz0.

I will attached the graphics card info of the Mac machines.

Please let me know if you need any other clarifications.
Comment 85 Vishvesh 2011-10-19 06:48:43 PDT
Created attachment 568032 [details]
Hardware info of the mac machine on which the build didn't render the animation
Comment 86 Vishvesh 2011-10-19 07:19:37 PDT
Created attachment 568038 [details]
List of Macintosh Hardware on which build is working
Comment 87 Benoit Girard (:BenWa) 2011-10-19 07:26:39 PDT
I did some testing as well, we don't want to purse the build from Comment 77.
Comment 88 Benoit Girard (:BenWa) 2011-10-19 11:44:10 PDT
Created attachment 568138 [details] [diff] [review]
Don't use async plugin for CoreAnimation (Non ICA)

Try build coming up
Comment 89 Mozilla RelEng Bot 2011-10-19 16:10:27 PDT
Try run for 27349b705abd is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=27349b705abd
Results (out of 2 total builds):
    success: 2
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-27349b705abd
Comment 90 Vishvesh 2011-10-19 20:37:19 PDT
(In reply to Benoit Girard (:BenWa) from comment #88)
> Created attachment 568138 [details] [diff] [review] [diff] [details] [review]
> Don't use async plugin for CoreAnimation (Non ICA)
> 
> Try build coming up

I will be testing the build Thanks.
Comment 91 Steven Michaud [:smichaud] (Retired) 2011-10-20 14:07:05 PDT
Comment on attachment 568138 [details] [diff] [review]
Don't use async plugin for CoreAnimation (Non ICA)

I tested the build made from this patch (from comment #89) on OS X 10.7.2.  I had no problems.

I tested with the NetscapeCoreAnimationPlugin and with http://trailers.apple.com/trailers/independent/beingelmo/ (QuickTime media).

Note that, because of bug 687610 and bug 670036, you need to clear the network
cache before running any QuickTime test.
Comment 92 Shiv 2011-10-21 08:20:27 PDT
Tested with build with a CAOpenGLLayer based plugin. 

Following is the result
============================================================
|  OS    |       Graphics Card                |    Result  |
============================================================
|  10.6  |       ATI Radeon X1600             |     Fail   |
|  10.7  |      ATI Radeon HD 2600 Pro        |     Pass   |
|  10.6  |       NVIDIA GeForce GT 330M       |     Pass   |
|  10.6  |        NVIDIA GeForce 9400M        |     Fail   |
|  10.6  |        ATI Radeon HD 2600 Pro      |     Fail   |
|  10.6  |        Intel HD Graphics           |     Pass   |
============================================================

Pass meaning plugin renders animation.
Fails meaning No animation seen.
Comment 93 Benoit Girard (:BenWa) 2011-10-21 08:27:22 PDT
The ATI Radeon X1600 doesn't get layers acceleration so it should be unaffected with these changes. Are all of these working with Firefox 7.0?
Comment 94 Shiv 2011-10-21 10:03:34 PDT
Yes all these work with Firefox 7.0
Comment 95 Steven Michaud [:smichaud] (Retired) 2011-10-21 11:23:39 PDT
Shiv, could you try to find which mozilla-central nightly (or
nightlies) your problem(s) started with?  Since you may have more than
one problem, there may be more than one regression range.

mozilla-central nightlies (and other kinds of nightlies) are available
at ftp://ftp.mozilla.org/pub/firefox/nightly/.
Comment 96 Steven Michaud [:smichaud] (Retired) 2011-10-21 12:07:11 PDT
Another thing, Shiv:  In your tests please test with plugins.use_layers set to false.
Comment 97 Vishvesh 2011-10-24 07:49:18 PDT
(In reply to Steven Michaud from comment #96)
> Another thing, Shiv:  In your tests please test with plugins.use_layers set
> to false.

(In reply to Steven Michaud from comment #95)
> Shiv, could you try to find which mozilla-central nightly (or
> nightlies) your problem(s) started with?  Since you may have more than
> one problem, there may be more than one regression range.
> 
> mozilla-central nightlies (and other kinds of nightlies) are available
> at ftp://ftp.mozilla.org/pub/firefox/nightly/.

Continuing from where shiv had left. I tested most of the build from October to July. The issue started with firefox-8.0a1 nightly build of July 14. The build is available at ftp://ftp.mozilla.org/pub/firefox/nightly/2011/07/2011-07-14-04-02-53-mozilla-inbound/firefox-8.0a1.en-US.mac.dmg

I tested builds of July 13 to July 10. There were no issues with them. Hope this helps.
Comment 98 Vishvesh 2011-10-24 08:03:01 PDT
I tested this on machines having Intel HD Graphics card and NVIDIA GeForce 9400M. July 14th build failed to render on both the machines.
Comment 99 Benoit Girard (:BenWa) 2011-10-24 08:11:45 PDT
Can you test with this build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-27349b705abd
Comment 100 Steven Michaud [:smichaud] (Retired) 2011-10-24 08:13:12 PDT
(In reply to comment #97)

> Hope this helps.

Thanks!

As best I can tell, there's only one patch in this range that might
have caused your problem(s):

Bug 671189: Unblock for error replies to sync messages. r=bent
author      Chris Jones <jones.chris.g@gmail.com>
            Wed Jul 13 22:43:43 2011 -0700 (at Wed Jul 13 22:43:43 2011 -0700)
changeset 72763 bb74b8675a47
parent 72762    f70f630c3e80
child 72764     ae34a5fc1c3b
pushlog:        bb74b8675a47

I'll do a tryserver build with that change backed out, and post it
here for you (and others) to test.  It should be available sometime
this afternoon.
Comment 101 Steven Michaud [:smichaud] (Retired) 2011-10-24 12:44:45 PDT
(Following up comment #100)

Here's the tryserver build made with the patch for bug 671189 backed out.  Please test it with plugins.use_layers set to false.

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-fbddaeff01fa/try-macosx64/firefox-10.0a1.en-US.mac.dmg

Please also test Benoit's build from comment #99.  I think he wants you to test it with plugins.use_layers set to true (the current default).
Comment 102 Benoit Girard (:BenWa) 2011-10-24 12:59:04 PDT
(In reply to Steven Michaud from comment #101)
> Please also test Benoit's build from comment #99.  I think he wants you to
> test it with plugins.use_layers set to true (the current default).

Yes, that's correct. Thanks :)
Comment 103 Vishvesh 2011-10-24 20:30:35 PDT
(In reply to Benoit Girard (:BenWa) from comment #99)
> Can you test with this build?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.
> com-27349b705abd

(In reply to Steven Michaud from comment #101)
> (Following up comment #100)
> 
> Here's the tryserver build made with the patch for bug 671189 backed out. 
> Please test it with plugins.use_layers set to false.
> 
I will test both the builds today.
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-
> fbddaeff01fa/try-macosx64/firefox-10.0a1.en-US.mac.dmg
> 
> Please also test Benoit's build from comment #99.  I think he wants you to
> test it with plugins.use_layers set to true (the current default).
Comment 104 Vishvesh 2011-10-24 23:33:07 PDT
(In reply to Benoit Girard (:BenWa) from comment #99)
> Can you test with this build?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.
> com-27349b705abd

I tested this build. If I set plugins.use_layers to true. This build renders only single frame and after that nothing. But if I set plugins.use_layers to False. This build works fine on machine having Intel HD Graphics card.

The same build doesn't work on Macintosh machine having NVIDIA GeForce 9400M Graphics card with the flag turned to true and false.
Comment 105 Vishvesh 2011-10-25 00:12:17 PDT
(In reply to Steven Michaud from comment #101)
> (Following up comment #100)
> 
> Here's the tryserver build made with the patch for bug 671189 backed out. 
> Please test it with plugins.use_layers set to false.
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-
> fbddaeff01fa/try-macosx64/firefox-10.0a1.en-US.mac.dmg
> 
> Please also test Benoit's build from comment #99.  I think he wants you to
> test it with plugins.use_layers set to true (the current default).

The result is same as Benoit's build. If I set plugins.use_layers to false the build works fine on machine having Intel HD Graphics card but fails to render anything on machine having NVIDIA GeForce 9400M Graphics card.
Comment 106 Vishvesh 2011-10-25 00:26:51 PDT
(In reply to Vishvesh from comment #104)
> (In reply to Benoit Girard (:BenWa) from comment #99)
> > Can you test with this build?
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.
> > com-27349b705abd
> 
> I tested this build. If I set plugins.use_layers to true. This build renders
> only single frame and after that nothing. But if I set plugins.use_layers to
> False. This build works fine on machine having Intel HD Graphics card.
> 
> The same build doesn't work on Macintosh machine having NVIDIA GeForce 9400M
> Graphics card with the flag turned to true and false.

Sorry Benoit. I tested a wrong build. I will try your build again. Please ignore these statements.
Comment 107 Vishvesh 2011-10-25 01:17:49 PDT
I tested both the builds, 
Benoit : 
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-27349b705abd/try-macosx64/firefox-10.0a1.en-US.mac.dmg
plugins.use_layers = true

Steven Michaud : 
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-fbddaeff01fa/try-macosx64/firefox-10.0a1.en-US.mac.dmg
plugins.use_layers = false

Builds work fine on machine having Intel HD Graphics card but fails to render anything on machine having NVIDIA GeForce 9400M Graphics card.
Comment 108 Vishvesh 2011-10-25 05:30:52 PDT
Just to add to the issue. I used BasicMediaPlayer.plugin of FireBreath 1.6 on my machine having NVIDIA GeForce 9400M Graphics card. The nightly builds did not render anything. While on my other machine with Intel HD Graphics card there was a constant flicker, which is also seen on Firefox 8.

BasicMediaPlayer.plugin of FireBreath 1.6 uses InvalidateRect event.
Comment 109 Steven Michaud [:smichaud] (Retired) 2011-10-25 09:34:32 PDT
(In reply to comment #107)

> Steven Michaud :
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-fbddaeff01fa/try-macosx64/firefox-10.0a1.en-US.mac.dmg
> plugins.use_layers = false
>
> Builds work fine on machine having Intel HD Graphics card but fails
> to render anything on machine having NVIDIA GeForce 9400M Graphics
> card.

So apparently the patch for bug 671189 didn't trigger this problem.

I'll come up with another guess, and prepare another tryserver build.
Comment 110 Steven Michaud [:smichaud] (Retired) 2011-10-25 13:56:22 PDT
> So apparently the patch for bug 671189 didn't trigger this problem.
>
> I'll come up with another guess, and prepare another tryserver build.

I'm still working on this.  In the meantime, Vishvesh, could you test
both of the following nightlies (with plugins.use_layers false)?  Note
that they are both mozilla-central nightlies (not mozilla-inbound
nightlies).

ftp://ftp.mozilla.org/pub/firefox/nightly/2011/07/2011-07-13-03-07-41-mozilla-central/firefox-8.0a1.en-US.mac.dmg
ftp://ftp.mozilla.org/pub/firefox/nightly/2011/07/2011-07-14-03-07-48-mozilla-central/firefox-8.0a1.en-US.mac.dmg
Comment 111 Steven Michaud [:smichaud] (Retired) 2011-10-25 15:15:39 PDT
Vishvesh:  For completeness sake please also test this nightly (with plugins.use_layers set to false):

ftp://ftp.mozilla.org/pub/firefox/nightly/2011/07/2011-07-15-14-04-43-mozilla-central/firefox-8.0a1.en-US.mac.dmg
Comment 112 Steven Michaud [:smichaud] (Retired) 2011-10-25 15:26:41 PDT
And here are two more builds to test with, Vishvesh.  Once again
please test with plugins.use_layers set to false.

They are built from mozilla-central code as of when a particular patch
was landed, at different times on 2011-07-14.  The one labeled
0141c3f5b18c corresponds to the patch for bug 670508.  The one labeled
a0ea3fd86f20 corresponds to the last of the patches for bug 684484.

They aren't tryserver builds (the tryserver can't do builds like
that).  Instead they're custom builds that I made.  Their symbols
aren't stripped, and they have optimization turned off, but they
aren't (technically) "debug builds".

http://people.mozilla.com/~stmichaud/bmo/firefox-8.0a1.en-US.mac-0141c3f5b18c.dmg
http://people.mozilla.com/~stmichaud/bmo/firefox-8.0a1.en-US.mac-a0ea3fd86f20.dmg
Comment 113 Steven Michaud [:smichaud] (Retired) 2011-10-25 15:27:49 PDT
> The one labeled a0ea3fd86f20 corresponds to the last of the patches
> for bug 684484.

That should be bug 648484.
Comment 114 Vishvesh 2011-10-26 19:33:55 PDT
Thanks Steven. I will test all the five builds and provide feedback on it. I appreciate all the help you guys have been providing.
Comment 115 Vishvesh 2011-10-26 20:12:04 PDT
(In reply to Steven Michaud from comment #110)
> > So apparently the patch for bug 671189 didn't trigger this problem.
> >
> > I'll come up with another guess, and prepare another tryserver build.
> 
> I'm still working on this.  In the meantime, Vishvesh, could you test
> both of the following nightlies (with plugins.use_layers false)?  Note
> that they are both mozilla-central nightlies (not mozilla-inbound
> nightlies).
> 
> ftp://ftp.mozilla.org/pub/firefox/nightly/2011/07/2011-07-13-03-07-41-
> mozilla-central/firefox-8.0a1.en-US.mac.dmg
> ftp://ftp.mozilla.org/pub/firefox/nightly/2011/07/2011-07-14-03-07-48-
> mozilla-central/firefox-8.0a1.en-US.mac.dmg

What is the difference between inbound and central nightly?
Comment 116 Vishvesh 2011-10-26 21:03:16 PDT
(In reply to Steven Michaud from comment #110)
> > So apparently the patch for bug 671189 didn't trigger this problem.
> >
> > I'll come up with another guess, and prepare another tryserver build.
> 
> I'm still working on this.  In the meantime, Vishvesh, could you test
> both of the following nightlies (with plugins.use_layers false)?  Note
> that they are both mozilla-central nightlies (not mozilla-inbound
> nightlies).
> 
> ftp://ftp.mozilla.org/pub/firefox/nightly/2011/07/2011-07-13-03-07-41-
> mozilla-central/firefox-8.0a1.en-US.mac.dmg
> ftp://ftp.mozilla.org/pub/firefox/nightly/2011/07/2011-07-14-03-07-48-
> mozilla-central/firefox-8.0a1.en-US.mac.dmg

All the builds seem to work correctly on Intel HD Graphics card. Need to test them on NVIDIA GeForce 9400M Graphics card.
Comment 117 Benoit Girard (:BenWa) 2011-10-26 21:04:50 PDT
Inbound is a branch where developers check their changes in. It is merged daily or so (not necessarily nightly like nightly builds) with mozilla-central once the changes have passed all automated tests. The branch should be treated as even less stable that mozilla-central. This makes it so that changes that fail automated tests wont make it to mozilla-central.

Changes will typically hit inbound a day before central, however a developer can land directly to mozilla-central in which case the mozilla-inbound branch will get the change latter.
Comment 118 Vishvesh 2011-10-26 23:03:32 PDT
Thanks Girard.
Comment 119 Vishvesh 2011-10-28 23:26:05 PDT
(In reply to Steven Michaud from comment #112)
> And here are two more builds to test with, Vishvesh.  Once again
> please test with plugins.use_layers set to false.
> 
> They are built from mozilla-central code as of when a particular patch
> was landed, at different times on 2011-07-14.  The one labeled
> 0141c3f5b18c corresponds to the patch for bug 670508.  The one labeled
> a0ea3fd86f20 corresponds to the last of the patches for bug 684484.
> 
> They aren't tryserver builds (the tryserver can't do builds like
> that).  Instead they're custom builds that I made.  Their symbols
> aren't stripped, and they have optimization turned off, but they
> aren't (technically) "debug builds".
> 
> http://people.mozilla.com/~stmichaud/bmo/firefox-8.0a1.en-US.mac-
> 0141c3f5b18c.dmg
> http://people.mozilla.com/~stmichaud/bmo/firefox-8.0a1.en-US.mac-
> a0ea3fd86f20.dmg

All the builds work fine with plugins.use_layers set to false.
The graphics card tested were 

Following is the result
============================================================
|  OS    |       Graphics Card                |    Result  |
============================================================
|  10.6  |       ATI Radeon X1600             |     Pass   |
|  10.7  |      ATI Radeon HD 2600 Pro        |     Pass   |
|  10.6  |       NVIDIA GeForce GT 330M       |     Pass   |
|  10.6  |        NVIDIA GeForce 9400M        |     Pass   |
|  10.6  |        ATI Radeon HD 2600 Pro      |     Pass   |
|  10.6  |        Intel HD Graphics           |     Pass   |
============================================================
Comment 120 Vishvesh 2011-10-28 23:29:27 PDT
I have got few questions 
1. How long would it take to move these changes to trunk(FF8)?
2. What was the fix?
3. Is it needed to set "plugins.use_layers" to false before using Core animation based plugin?
Comment 121 Steven Michaud [:smichaud] (Retired) 2011-10-29 08:17:29 PDT
Vishvesh, please test all five builds that I asked you to test, including those from comment #111 and comment #112.  I'm only interested in tests on those machines where some tests didn't pass with plugins.use_layers set to false.  I'm trying to find the patch that caused some problems not to be fixable by turning off plugins.use_layers.

> 2. What was the fix?

To make plugins.use_layers default to false.
Comment 122 Steven Michaud [:smichaud] (Retired) 2011-10-29 08:32:12 PDT
The patch that fixed this bug (which made plugins.use_layers default
to false) was landed at bug 663259.  It turned off the changes that
had earlier been made by the patch for bug 663259, without actually
backing them out.

However, you and Shiv have given us evidence that some problems
started happening around the time that the patch that bug 663259
landed on the trunk (aka mozilla-central), which *can't* be fixed just
by setting plugins.use_layers to false.	 And since the patch for bug
663259 wasn't backed out, maybe some	part of	it is causing your
problems even when it's	changes	are (we	think) turned off.  Or maybe
the cause is some other patch landed around the same time.

That's why your tests are so important to us -- we want to find out
what triggered these problems.  (The patch for bug 663259 landed on
mozilla-central on 2011-07-13, and appears in the 2011-07-14 and
subsequent mozilla-central nightlies.)
Comment 123 Steven Michaud [:smichaud] (Retired) 2011-10-29 08:38:16 PDT
> 1. How long would it take to move these changes to trunk(FF8)?

The "backout" patch at bug 663259 (the one that (we hope) turns off
the effects of the changes made by the original patch for that bug)
has already landed on mozilla-central and the beta branch.  That means
it's present in current mozilla-central nightlies, and will be present
in the next FF8 beta, and also in the FF8 release (when that happens).

> 3. Is it needed to set "plugins.use_layers" to false before using
>    Core animation based plugin?

My understanding is that setting plugins.use_layers to false makes us
treat plugins that do Invalidating Core Animation exactly the same as
those that do Core Animation.  But that may not be right.

Benoit?
Comment 124 Vishvesh 2011-10-30 06:16:18 PDT
(In reply to Steven Michaud from comment #121)
> Vishvesh, please test all five builds that I asked you to test, including
> those from comment #111 and comment #112.  I'm only interested in tests on
> those machines where some tests didn't pass with plugins.use_layers set to
> false.  I'm trying to find the patch that caused some problems not to be
> fixable by turning off plugins.use_layers.
> 
> > 2. What was the fix?
> 
> To make plugins.use_layers default to false.

I have tested the builds of comment 111 and 112. The report in comment 119 includes report for those build and they are working on the machine where it had failed previously. Last time when I had tested them plugins.use_layers was set to true.
Comment 125 Vishvesh 2011-11-01 23:57:41 PDT
Any updates on this Issue. Any idea on the release date of Firefox 8. Is it still going to be November 8?
Comment 126 Vishvesh 2011-11-02 00:12:42 PDT
(In reply to Steven Michaud from comment #123)
> > 1. How long would it take to move these changes to trunk(FF8)?
> 
> The "backout" patch at bug 663259 (the one that (we hope) turns off
> the effects of the changes made by the original patch for that bug)
> has already landed on mozilla-central and the beta branch.  That means
> it's present in current mozilla-central nightlies, and will be present
> in the next FF8 beta, and also in the FF8 release (when that happens).
> 
> > 3. Is it needed to set "plugins.use_layers" to false before using
> >    Core animation based plugin?
> 
> My understanding is that setting plugins.use_layers to false makes us
> treat plugins that do Invalidating Core Animation exactly the same as
> those that do Core Animation.  But that may not be right.
> 
> Benoit?

I missed out few comments. Looks like changes are already in firefox 8 beta.
Comment 127 Vishvesh 2011-11-02 01:46:15 PDT
Is this a clean fix or a temporary work around?
Comment 128 Benoit Girard (:BenWa) 2011-11-02 08:51:12 PDT
It's a clean fix for 8.0, 9.0 since the feature was turned off. It is temporary because the feature will be re-enabled once the problems are addressed.
Comment 129 Vishvesh 2011-11-02 23:01:37 PDT
(In reply to Benoit Girard (:BenWa) from comment #128)
> It's a clean fix for 8.0, 9.0 since the feature was turned off. It is
> temporary because the feature will be re-enabled once the problems are
> addressed.

Thanks.
Comment 130 Vishvesh 2011-12-10 00:02:42 PST
I see this issue again on Firefox 9 beta build. In the build plugins.use_layers is set o false.
Comment 131 Vishvesh 2011-12-12 07:21:35 PST
Any updates on this issue?
Comment 132 Benoit Girard (:BenWa) 2011-12-12 07:49:01 PST
I just tested with Firefox 9 beta and Quicktime renders fine for me. Do you any additional info?
Comment 133 Vishvesh 2011-12-12 22:41:14 PST
The problem is with plugins using CAOpenGLLayer.

Rendering is fine on some machines but on some other machines animation is not seen.

Following is the result
============================================================
|  OS    |       Graphics Card                |    Result  |
============================================================
|  10.6  |       ATI Radeon X1600             |     Fail   |
|  10.6  |       NVIDIA GeForce GT 330M       |     Pass   |
|  10.6  |        NVIDIA GeForce 9400M        |     Fail   |
|  10.6  |        ATI Radeon HD 2600 Pro      |     Fail   |
|  10.6  |        Intel HD Graphics           |     Pass   |
============================================================

Pass meaning plugin renders animation.
Fails meaning No animation seen.
Comment 134 Vishvesh 2011-12-20 06:46:37 PST
Any updates on the issue?
Comment 135 Benoit Girard (:BenWa) 2011-12-20 07:24:01 PST
I can reproduce the bug but only manually setting plugins.use_layers to be true. Can you try to reproduce the bug with a fresh profile? I suspect you have a preference that is interfering with the default configuration.

I have tested on a:
- AMD Radeon HD 6750M
- ATI Radeon HD 5770
Comment 136 Vishvesh 2011-12-21 00:17:35 PST
Can you please share the plug-in you had used for testing?
Comment 137 Vishvesh 2011-12-21 04:09:37 PST
I created new user account and tried it again. I can still reproduce the issue. It would be good if you could share the plug-in you had used for testing.
Comment 138 Vishvesh 2011-12-22 00:26:36 PST
(In reply to Benoit Girard (:BenWa) from comment #135)
> I can reproduce the bug but only manually setting plugins.use_layers to be
> true. Can you try to reproduce the bug with a fresh profile? I suspect you
> have a preference that is interfering with the default configuration.
> 
> I have tested on a:
> - AMD Radeon HD 6750M
> - ATI Radeon HD 5770

The issue is not seen on all ATI graphics card. There are some Intel graphics card on which the rendering doesn't happen.  I can try to regenerate with your plug-in.
Comment 139 Benoit Girard (:BenWa) 2011-12-22 08:42:13 PST
I've been using Quicktime. I'll get a hold of a NVIDIA machine to test.
Comment 140 Vishvesh 2011-12-22 22:03:10 PST
I am not sure whether Quicktime uses CAOpenGLLayer. I am seeing this issues with plug-ins using CAOpenGLLayer for drawing.
Comment 141 Vishvesh 2011-12-29 06:03:28 PST
(In reply to Benoit Girard (:BenWa) from comment #139)
> I've been using Quicktime. I'll get a hold of a NVIDIA machine to test.

I was debugging this issue, it looks like "-(BOOL)canDrawInCGLContext:(CGLContextObj)glContext  ..." is not getting called on certain machines. Any idea on what could cause this issue.
Comment 142 Benoit Girard (:BenWa) 2011-12-29 14:04:31 PST
I've just tried Quicktime on a X1600 and it work. This issue no longer applies to the current bug report. Can you open a new bug report with detailed STR, what plugins to use with which hardware and CC me?
Comment 143 Vishvesh 2011-12-29 21:46:48 PST
okay
Comment 144 jonas echterhoff 2012-01-18 01:52:27 PST
We are seeing the same bug in unity. Try installing the unity plugin, and going to http://unity3d.com/gallery/demos/live-demos to see the problem. In Firefox 10, when running in 64 bit mode, this shows very bad flicker.
Comment 145 Benoit Girard (:BenWa) 2012-01-18 07:04:44 PST
(In reply to jonas echterhoff from comment #144)
> We are seeing the same bug in unity. Try installing the unity plugin, and
> going to http://unity3d.com/gallery/demos/live-demos to see the problem. In
> Firefox 10, when running in 64 bit mode, this shows very bad flicker.

Filed as bug 719025, this isn't the right place to discuss this.
Comment 146 Benoit Girard (:BenWa) 2012-01-18 07:09:28 PST
(In reply to Benoit Girard (:BenWa) from comment #142)
> I've just tried Quicktime on a X1600 and it work. This issue no longer
> applies to the current bug report. Can you open a new bug report with
> detailed STR, what plugins to use with which hardware and CC me?

Bug 714723 was filed where we found it was caused by partial landing of the Offline renderer support. Closing this bug.

Note You need to log in before you can comment on or make changes to this bug.