User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0a1) Gecko/20110607 Firefox/7.0a1
I believe this started when bug 598425 landed.
Whenever the volume control or the seeker bar animated the video will freeze for a fraction of a second or so or the FPS will drop slightly depending on the video.
Steps to Reproduce:
1. Goto http://www.youtube.com/watch?v=oLwJT-HhhB0
2. Let the video load a bit.
3. Mouse over the player so the seeker bar expands while the video is playing
Running latest nightly of Firefox and latest Flash version (10.3.181.22) on a MacBook Pro (Late 2008).
I assume these problems don't happen with the last mozilla-central nightly that didn't include the patch for bug 598425 (dated 2011-06-05) ... or do they? :-)
Playback is smooth with nightly from the 5th, playing it with nightly from the 6th and 7th causes the freezing.
*** Bug 662569 has been marked as a duplicate of this bug. ***
What's happening is while the bar resizes we get invalidate rects only for the playback bar when we should be getting it for the bar+video region. There several similar instances where only a sub region of what is changing will repaint because we receive the wrong rect from the plugin.
The fix here is to either (1) always redraw everything at the cost of performance or (2) file bugs with the plugins.
You're sure that we don't get *separate* invalidates for the bar and the playback region, and we're just not making the region union correctly?
For what it's worth, I can reproduce this bug. I mention this because
I haven't been able to reproduce a couple of other bugs that have been
reported on the patch for bug 598425 (bug 662347 and bug 662843).
I tested with the firefox-2011-06-05-03-mozilla-central and
firefox-2011-06-06-03-mozilla-central nightlies on OS X 10.6.7 running
on a 2.5-year-old MacBook Pro. The second of these two nightlies is
the first that contained the patch for bug 598425. I only saw the bug
with the second nightly.
Benjamin is correct, I union the rect incorrectly as I misunderstood the API call.
I don't see the problem on a local build, but I see it on nightlies. I believe flash may be asking for a different rendering model (is it looking at the UA here?). Taking a quick look at this before I post a patch, since it will help me test.
Actually the api usage was correct. I compared the profile with about:support and could not find a difference. I now realized that about:support does not show when a new preference is added thus did not notice that I had set 'mozilla.plugins.use_layers' early on in testing. Filed bug 663187 about this.
Turns out that async rendering was not activated properly in the nightlies. I will post a patch shortly after it has been tested.
Setting mozilla.plugins.use_layers to true and I'm no longer seeing this bug. Also solved bug 618318 for me.
Thanks for the help debugging this problem. I hope to land a patch as soon as all the tests pass.
(In reply to comment #11)
Pong. Did I miss a question?
The problem will be resolved once bug 610441 lands.
The async painting is is off by default on Aurora and we're not likely to enable it so minusing for tracking.
I landed the changes to bug 663259. Async plugin should be on by default and this bug should be fixed. Does someone care to verify?
I can no longer see this, nor the flickering described in bug 663259. I do however still experience bug 618318, however not as severe as before async plugins landed.