Created attachment 8553326 [details] plugin_test.html On Mac, when a plugin (e.g. Flash) is running on a page, the whole browser window is constantly re-painting itself, even though the window UI is not changing. This can be seen through Quartz Debug (from Xcode.app) when enabling the "Flash identical screen updates" option, and Firefox is running a plugin (see attached HTML file for an example). Stopping the plugin will stop the window re-painting as well. Note: This is not a new regression - it's been happening for a long time (in previous versions of Firefox).
Milan/Benjamin/Georg/Steven, who knows about this? :-)
Component: General → Untriaged
Product: Firefox → Core
Here are a couple more people who might know what's going on. I certainly don't.
Todd, I can't get your testcase to display anything (testing in FF 35, the current release).
We had a regression but I don't think it was in 35. Can you post about:support here and try the lastest nightly build to see if the issue is resolved?
@steven > I can't get your testcase to display anything (testing in FF 35, the current release). Try downloading the html file (as Bugzilla might be protecting you there), or creating a html file with this simple flash content and opening it in Firefox: <body> <embed type="application/x-shockwave-flash" autoplay="yes" loop="no" width="400" height="300" src="http://samples.mplayerhq.hu/SWF/test.swf" /> </body> > try the lastest nightly build to see if the issue is resolved? Not resolved in latest nightly - it looks the same. Will attach about:support from nightly build. My limited guess, something in gfx/layers/base code with invalidation or compositing of plugins?
Your testcase doesn't render for me or trigger painting for me and going to the URL directly crashes my browser: http://samples.mplayerhq.hu/SWF/test.swf We should file a bug to see why that crashes. Todd can you run mozregression: http://mozilla.github.io/mozregression/ It's a binary search using precompiled nightly binaries and typically takes about 12 iterations IIRC to find which day the bad change that landed. Narrowing down the change is typically very useful.
Sorry, but I don't think mozregression is going to help here, as I can repro this on Firefox 4.0 for example (not sure how far mozregression runs back). I suspect this bug has been around forever, or at least since Mac cocoa 64 bit builds were made. As for testcase not working - are you blocking Flash plugins (about:addons > Plugins)?
Simpler test case is just to visit (thanks Ben): http://samples.mplayerhq.hu/SWF/test.swf as that shows the same symptoms (and I guess runs flash as a plugin).
It's not just us. I see the same problem in Safari and Chrome. I tested on OS X 10.7.5 (using Quartz Debug from the Graphics Tools for XCode, August 2012 -- the latest download for Mountain Lion).
Graphics Tools for XCode, August 2012 -- the latest download for Lion
Is Flash using NPDrawingModelCoreAnimation or NPDrawingModelInvalidatingCoreAnimation? We really need it to be using Invalidating or else every Flash element will have constant 60fps paint requests.
> It's not just us. I see the same problem in Safari and Chrome. Sort of - Chrome and Safari are re-painting Content, but Firefox is painting Content and Chrome (e.g. the tabs and bookmarks sidebar if you had it opened).
This isn't painting, it's recompositing. When a frame changes we need to recomposite the full window. Chrome and Safari uses a native view for their UI. This is an architectural decision.
(In reply to comment #14) Now I notice it's true that Safari doesn't "repaint" chrome -- only content. But Chrome seems to "repaint" both. The same problem happens with Silverlight objects as with Flash objects: http://www.vectorlight.net/silverlight/demos.aspx I *think* at least one of Silverlight or Flash uses NPDrawingModelInvalidatingCoreAnimation. Does anyone remember?
> But Chrome seems to "repaint" both. Not for me, Chrome (version 40.0.2214.91 64-bit) does not repaint the chrome content (i.e. tabs, url bar, or developer console when opened). Yes, I'm pretty sure Flash does use NPDrawingModelInvalidatingCoreAnimation. > This isn't painting, it's recompositing. This is an architectural decision. I don't quite understand how "recompositing" works for Firefox, but I assume you mean Firefox is using one native NSView/NSWindow for the whole Firefox (chrome+content) window, and the plugin will repaint into a specific layer, and then Firefox combines all layers which will invalidation/update the window as a whole? Anyway, if it's an architectural decision (and not a bug), then I'm inclined to mark as WONTFIX and move on :)
Yes, it's expected. If there's a significant difference in performance or power usage that's another story.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
Summary: plugins causing unnecessary window repainting (performance, mac) → plugins invalidating causes the full window to be recomposited
Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598
Component: Untriaged → General
You need to log in before you can comment on or make changes to this bug.