Closed
Bug 827201
Opened 12 years ago
Closed 9 years ago
FlickrExplorer performance regression with 18+
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
INCOMPLETE
Tracking | Status | |
---|---|---|
firefox17 | --- | unaffected |
firefox18 | - | wontfix |
firefox19 | + | wontfix |
firefox20 | + | wontfix |
firefox-esr17 | --- | unaffected |
People
(Reporter: Rythestampede, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: perf, regression, reproducible, Whiteboard: [ietestdrive])
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232
Steps to reproduce:
ie.microsoft.com/testdrive/Performance/FlickrExplorer/Default.html
Actual results:
FF 18 displays this benchmark slowly.
Expected results:
Should run like 17 which runs smoothly.
Did you try with hardware acceleration disabled? (Options > Advanced > General, then restart FF)
Same result?
Flags: needinfo?(Rythestampede)
Comment 2•12 years ago
|
||
Steps to reproduce (For the exploration of the regression range)
1. Reduce size of the browser window (i.e., half width of screen)
2. Open URL http://ie.microsoft.com/testdrive/Performance/FlickrExplorer/Default.html
3. Wait until the movement of the thumbnail is completed(to avoid random effect)
4. Maximize browser window
--- observe rendering speed
5. Restore browser window size
--- observe rendering speed
Actual results:
Very slow rendering
Regression window(cached m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/ff86ec766232
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20121001112917
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/c0873dd40e2d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20121001115917
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ff86ec766232&tochange=c0873dd40e2d
Suspected : Bug 486918
Strangely to say,
Setting image.high_quality_downscaling.enabled=true/false does not change anything.
Blocks: 486918
Status: UNCONFIRMED → NEW
status-firefox17:
--- → unaffected
status-firefox-esr17:
--- → unaffected
tracking-firefox18:
--- → ?
tracking-firefox19:
--- → ?
tracking-firefox20:
--- → ?
Component: Untriaged → ImageLib
Ever confirmed: true
Keywords: perf,
regression
Product: Firefox → Core
FWIW, disabling hardware acceleration does avoid this regression.
Flags: needinfo?(Rythestampede)
Comment 4•12 years ago
|
||
In local build
Last good: 717fb1afa612
First bad: 780d5ccc064c
Comment 5•12 years ago
|
||
We're assuming this will mostly impact large amounts of image scaling, given the relation to bug 486918. If that's the case, this is likely an uncommon user scenario. We'd accept a low risk uplift, but may not decide to track for release.
Joe, can you help verify our understanding?
Comment 6•12 years ago
|
||
I'm very surprised by
> Setting image.high_quality_downscaling.enabled=true/false does not change anything.
Even so, I suspect that your understanding is right, Alex, but I'm going to look at a profile to try to verify.
Comment 7•12 years ago
|
||
Profile with hardware acceleration: http://people.mozilla.com/~bgirard/cleopatra/#report=dff6c64bc94511552245f6089a7066d9d8c27dc0
Comment 8•12 years ago
|
||
Profile without hardware acceleration: http://people.mozilla.com/~bgirard/cleopatra/#report=6305899ca477bd1fde84bb734899e80f35ff3902
Comment 9•12 years ago
|
||
And I can verify that with hardware acceleration but without high_quality_downscaling, we see no difference. At a first glance, it looks like we're spending all of our time reuploading textures.
Comment 10•12 years ago
|
||
Actually I'm not convinced I can't see a difference without high_quality_downscaling, though it does look a lot better in earlier versions of Firefox.
The problem with the regression window is that as of 780d5ccc064c there was no way to turn off downscaling; that came in a subsequent patch. With that turned off, though, we still have a very slow start (~10fps) to the Flickr Explorer demo.
Alex, I can now verify that the biggest regression we have here is from lots of downscaled images, but it's not the only regression, unfortunately.
Comment 11•12 years ago
|
||
Bas, I'm pretty sure that there's a regression in uploading here (in addition to the downscaling regression) - can you look at some of the profiles and see if anything twigs in your mind?
Comment 12•12 years ago
|
||
Bas, this bug shows a very clear regression from 17->18 on the startup of Flickr Explorer (when the images are zooming in). To be sure you're not seeing the image downscaling regression, change image.high_quality_downscaling.enabled to false.
Flags: needinfo?(bas)
Comment 13•12 years ago
|
||
(In reply to Joe Drew (:JOEDREW! \o/) from comment #12)
> Bas, this bug shows a very clear regression from 17->18 on the startup of
> Flickr Explorer (when the images are zooming in). To be sure you're not
> seeing the image downscaling regression, change
> image.high_quality_downscaling.enabled to false.
Nothing rings a bell, Azure was also shipped in 17 so I doubt that's related. At this point unless you want me to do some profiling of my own I can't really help. If you need more info let me know.
Flags: needinfo?(bas)
Comment 14•12 years ago
|
||
(In reply to Bas Schouten (:bas.schouten) from comment #13)
> (In reply to Joe Drew (:JOEDREW! \o/) from comment #12)
> > Bas, this bug shows a very clear regression from 17->18 on the startup of
> > Flickr Explorer (when the images are zooming in). To be sure you're not
> > seeing the image downscaling regression, change
> > image.high_quality_downscaling.enabled to false.
>
> Nothing rings a bell, Azure was also shipped in 17 so I doubt that's
> related. At this point unless you want me to do some profiling of my own I
> can't really help. If you need more info let me know.
One thing I do notice is there's lots of upload going on, I wonder if perhaps we're not caching downscaled images properly?
Updated•12 years ago
|
Updated•12 years ago
|
Whiteboard: [ietestdrive]
Comment 15•12 years ago
|
||
(In reply to Joe Drew (:JOEDREW! \o/) from comment #10)
> Alex, I can now verify that the biggest regression we have here is from lots
> of downscaled images, but it's not the only regression, unfortunately.
Can we break this bug out into actionable subtasks, and track the biggest regression? If we don't resolve in the next few days in a low risk fashion, this will sadly go unfixed in FF19 as well.
Updated•12 years ago
|
status-firefox19:
--- → wontfix
Comment 16•12 years ago
|
||
What I think we need to do here: Add a timeout for when we allow high quality downscaling based on drawn size changes, and back off as resize frequency goes up.
Comment 17•12 years ago
|
||
I don't know if it's a regression, but I see the same slowness on the OSX as well. 3-4fps in 19, 60fps in Safari.
OS: Windows 7 → All
Comment 18•12 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #17)
> I don't know if it's a regression, but I see the same slowness on the OSX as
> well. 3-4fps in 19, 60fps in Safari.
Same frame rate with hardware acceleration disabled.
Comment 19•12 years ago
|
||
With high quality image downscaling option activated, it actually goes a bit faster for me, at 5-6fps.
Comment 20•12 years ago
|
||
Setting images.dither from auto to off makes a big difference - 10fps+ with it off.
Comment 21•12 years ago
|
||
We're less than a week away from going to build on FF20 beta 4 (Tues Mar 12th) - if you have a speculative, low risk fix you'd like to try out on beta for this issue it would need to be landed on trunk, verified, then nominated for approval before then.
Updated•12 years ago
|
status-firefox20:
--- → wontfix
Reporter | ||
Comment 22•12 years ago
|
||
Was hoping this would have been fixed by now, might as well mark off FF21 as wont fix well. Maybe assign it to someone?
Updated•11 years ago
|
Assignee: joe → nobody
Updated•11 years ago
|
Blocks: ietestdrive
Comment 23•9 years ago
|
||
Closing this bug since the testcase no longer exists and we've made no progress in two years. Please reopen if you have any new leads.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Comment 24•9 years ago
|
||
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #23)
> Closing this bug since the testcase no longer exists and we've made no
> progress in two years. Please reopen if you have any new leads.
The code that was added by the regressing bug (bug 486918) has now been removed in favor of a better solution. So it's quite likely this has been fixed, if only we could test that though.
You need to log in
before you can comment on or make changes to this bug.
Description
•