Closed Bug 827201 Opened 11 years ago Closed 9 years ago

FlickrExplorer performance regression with 18+

Categories

(Core :: Graphics: ImageLib, defect)

x86_64
All
defect
Not set
normal

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)
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
Component: Untriaged → ImageLib
Ever confirmed: true
Keywords: perf, regression
Product: Firefox → Core
FWIW, disabling hardware acceleration does avoid this regression.
Flags: needinfo?(Rythestampede)
Version: 18 Branch → Trunk
In local build
Last good: 717fb1afa612
First bad: 780d5ccc064c
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?
Assignee: nobody → joe
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.
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.
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.
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?
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)
(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)
(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?
Whiteboard: [ietestdrive]
(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.
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.
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
(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.
With high quality image downscaling option activated, it actually goes a bit faster for me, at 5-6fps.
Setting images.dither from auto to off makes a big difference - 10fps+ with it off.
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.
Was hoping this would have been fixed by now, might as well mark off FF21 as wont fix well. Maybe assign it to someone?
Assignee: joe → nobody
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
(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.