If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

FlickrExplorer performance regression with 18+

RESOLVED INCOMPLETE

Status

()

Core
ImageLib
RESOLVED INCOMPLETE
5 years ago
2 years ago

People

(Reporter: Ryan, Unassigned)

Tracking

(Blocks: 1 bug, {perf, regression, reproducible})

Trunk
x86_64
All
perf, regression, reproducible
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox17 unaffected, firefox18- wontfix, firefox19+ wontfix, firefox20+ wontfix, firefox-esr17 unaffected)

Details

(Whiteboard: [ietestdrive], URL)

(Reporter)

Description

5 years ago
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.

Updated

5 years ago

Comment 1

5 years ago
Did you try with hardware acceleration disabled? (Options > Advanced > General, then restart FF)

Same result?
Flags: needinfo?(Rythestampede)

Comment 2

5 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
(Reporter)

Comment 3

5 years ago
FWIW, disabling hardware acceleration does avoid this regression.
Flags: needinfo?(Rythestampede)

Updated

5 years ago
Version: 18 Branch → Trunk

Comment 4

5 years ago
In local build
Last good: 717fb1afa612
First bad: 780d5ccc064c

Comment 5

5 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?
Assignee: nobody → joe
status-firefox18: --- → wontfix
tracking-firefox18: ? → -
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.
Profile with hardware acceleration: http://people.mozilla.com/~bgirard/cleopatra/#report=dff6c64bc94511552245f6089a7066d9d8c27dc0
Profile without hardware acceleration: http://people.mozilla.com/~bgirard/cleopatra/#report=6305899ca477bd1fde84bb734899e80f35ff3902
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?

Updated

5 years ago
tracking-firefox19: ? → +
tracking-firefox20: ? → +
Keywords: reproducible

Updated

5 years ago
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.

Updated

5 years ago
status-firefox19: --- → wontfix
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.
Blocks: 846759
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.
status-firefox20: --- → wontfix
No longer blocks: 846759
(Reporter)

Comment 22

5 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?
Assignee: joe → nobody
Blocks: 918620
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
Last Resolved: 2 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.