Closed
Bug 1124864
Opened 9 years ago
Closed 9 years ago
plugins invalidating causes the full window to be recomposited
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: twhitema, Unassigned)
Details
(Keywords: perf)
Attachments
(2 files)
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).
Comment 1•9 years ago
|
||
Milan/Benjamin/Georg/Steven, who knows about this? :-)
Comment 2•9 years ago
|
||
Here are a couple more people who might know what's going on. I certainly don't.
Comment 3•9 years ago
|
||
Todd, I can't get your testcase to display anything (testing in FF 35, the current release).
Comment 4•9 years ago
|
||
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?
Reporter | ||
Comment 5•9 years ago
|
||
@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?
Reporter | ||
Comment 6•9 years ago
|
||
Comment 7•9 years ago
|
||
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.
Reporter | ||
Comment 8•9 years ago
|
||
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)?
Reporter | ||
Comment 9•9 years ago
|
||
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).
Comment 10•9 years ago
|
||
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).
Comment 11•9 years ago
|
||
Graphics Tools for XCode, August 2012 -- the latest download for Lion
Comment 12•9 years ago
|
||
And Opera.
Comment 13•9 years ago
|
||
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.
Reporter | ||
Comment 14•9 years ago
|
||
> 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).
Comment 15•9 years ago
|
||
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.
Comment 16•9 years ago
|
||
(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?
Reporter | ||
Comment 17•9 years ago
|
||
> 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 :)
Comment 18•9 years ago
|
||
Yes, it's expected. If there's a significant difference in performance or power usage that's another story.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Updated•9 years ago
|
Summary: plugins causing unnecessary window repainting (performance, mac) → plugins invalidating causes the full window to be recomposited
Comment 19•7 years ago
|
||
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.
Description
•