Closed Bug 692759 Opened 13 years ago Closed 13 years ago

[OOPP] Firefox 8.0 not rendering Core-Animation-based plugins (like QuickTime) in 64-bit mode

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
8 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(firefox8+)

Status:
RESOLVED FIXED
Milestone:
mozilla10
Tracking Flags:
Tracking Status
firefox8 + ---

People

(Reporter: vishvesh.com, Assigned: BenWa)

References

(
URL
)

Details

Attachments

(6 files)

Freezed frame image. This is the only frame the browser shows
47.92 KB, image/jpeg
Details
Logging patch (not a fix)
10.25 KB, patch
Details | Diff | Splinter Review
TimerFix
13.53 KB, patch
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
Details
List of Macintosh Hardware on which build is working
22.50 KB, application/octet-stream
Details
Don't use async plugin for CoreAnimation (Non ICA)
7.06 KB, patch
Details | Diff | Splinter Review 
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.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Firefox 8.0 not rendering 64 bit Core Animation based plug-ins → [OOPP] Firefox 8.0 not rendering Core-Animation-based plugins in 64-bit mode
Severity: normal → major
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
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Benoit, how would you revise the NetscapeCoreAnimationPlugin to fix this problem?

Someone should open a WebKit bug on this.
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).
Summary: [OOPP] Firefox 8.0 not rendering Core-Animation-based plugins in 64-bit mode → [OOPP] Firefox 8.0 not rendering Core-Animation-based plugins (like QuickTime) in 64-bit mode
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.
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.
> 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
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.
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.)
(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 :-)
(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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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.
Is there a way to only use the timer when we "need" it (while a movie is playing)?
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.
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 ?
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.
tracking-firefox8: --- → ?
(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?
tracking-firefox8: ? → +
> 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.
(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
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?
> 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.
Which plugins are those? QuickTime doesn't use invalidting CA, right, so we wouldn't want to whitelist it?
>> 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.
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.
> 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?
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.
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.
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.
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).
Let's continue that discussion in bug 693727. I'm open to having a deprecation plan if required.
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.
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.
> 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?
(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.
> I think it might of used QuickDraw.

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

Josh?
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.
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.
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.
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.)
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.
By the way, here's my logging patch.  A tryserver build should be available by (I hope) the end of the day.
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.
Benoit, please answer my questions from comment #40.
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.
> 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.
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.
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.
> We should still prepare a deprecation plan for CA in bug 693727.

Yes!! :-)
Attached patch TimerFix — — Splinter Review 
Assignee: nobody → bgirard
Status: REOPENED → ASSIGNED

    
  

        Attachment #567136 -
        Flags: review?(smichaud)

    
    

    
  
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.

    
    

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

    
    

    
  
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.

    
    

    
  
(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'?

    
    

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

    
    

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

        Attachment #567136 -
        Flags: review?(smichaud) → review+

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
How can I check the build which fixed this issue? Can you please share the link to the build.

    
    

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

    
    

    
  
(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.)
Whiteboard: [inbound]

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/3c5e89543399
Status: ASSIGNED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla10

    
    

    
  
Help me understand: Is this issue also going to be fixed in Firefox 8 & 9 after it has been verified in Firefox 10?

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
  
Depends on: 695243

    
    

    
  
(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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

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

    
    

    
  
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.

    
    

    
  
(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;"

    
    

    
  
I have a build that fixes problem 1) building on try. I'm not sure why this only happens with certain plugins.

    
    

    
  
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

    
    

    
  
(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

    
    

    
  
Do you have any particular example of this in mind?

    
    

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

    
    

    
  
(In reply to Benoit Girard (:BenWa) from comment #79)
> Do you have any particular example of this in mind?

Is this regarding issue #2?

    
    

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

    
    

    
  
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.

    
    

    
  
I did some testing as well, we don't want to purse the build from Comment 77.

    
    

    
  


  
Try build coming up

    
    

    
  
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

    
    

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

    
    

    
  
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.

    
    

    
  
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?

    
    

    
  
Yes all these work with Firefox 7.0

    
    

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

    
    

    
  
Another thing, Shiv:  In your tests please test with plugins.use_layers set to false.

    
    

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

    
    

    
  
I tested this on machines having Intel HD Graphics card and NVIDIA GeForce 9400M. July 14th build failed to render on both the machines.

    
    

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

    
    

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

    
    

    
  
(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 :)

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
> 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

    
    

    
  
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

    
    

    
  
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

    
    

    
  
> The one labeled a0ea3fd86f20 corresponds to the last of the patches
> for bug 684484.

That should be bug 648484.

    
    

    
  
Thanks Steven. I will test all the five builds and provide feedback on it. I appreciate all the help you guys have been providing.

    
    

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

    
    

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

    
    

    
  
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.

    
    

    
  
Thanks Girard.

    
    

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

    
    

    
  
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?

    
    

    
  
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.

    
    

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

    
    

    
  
> 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?

    
    

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

    
    

    
  
Any updates on this Issue. Any idea on the release date of Firefox 8. Is it still going to be November 8?

    
    

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

    
    

    
  
Is this a clean fix or a temporary work around?

    
    

    
  
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.

    
    

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

    
    

    
  
I see this issue again on Firefox 9 beta build. In the build plugins.use_layers is set o false.

    
    

    
  
Any updates on this issue?

    
    

    
  
I just tested with Firefox 9 beta and Quicktime renders fine for me. Do you any additional info?

    
    

    
  
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.

    
    

    
  
Any updates on the issue?

    
    

    
  
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

    
    

    
  
Can you please share the plug-in you had used for testing?

    
    

    
  
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.

    
    

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

    
    

    
  
I've been using Quicktime. I'll get a hold of a NVIDIA machine to test.

    
    

    
  
I am not sure whether Quicktime uses CAOpenGLLayer. I am seeing this issues with plug-ins using CAOpenGLLayer for drawing.

    
    

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

    
    

    
  
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?

    
    

    
  
okay

    
    

    
  
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.

    
    

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

    
    

    
  
(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.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED

    
  
Product: Core → Core Graveyard

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: