The default bug view has changed. See this FAQ.

Large scaled images in SVG's cause choppy scrolling

VERIFIED FIXED in Firefox 23

Status

()

Core
Graphics
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: Ben Aiken, Assigned: roc)

Tracking

({perf, regression})

20 Branch
mozilla23
x86
Mac OS X
perf, regression
Points:
---

Firefox Tracking Flags

(firefox20 wontfix, firefox21 affected, firefox22- affected, firefox23 verified)

Details

Attachments

(7 attachments, 2 obsolete attachments)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31

Steps to reproduce:

Scrolling around on a page with a very large image (6000px x 6000px, 54dpi) that is scaled down causes choppy scrolling. Occurs on Firefox v18+ on OSX. Does not seem to occur in versions 17 and prior.


Actual results:

The browser window stutters immensely.


Expected results:

There shouldn't be chopping scrolling. Seems to have been introduced in v18 of Firefox for OSX. Confirmed that it happens with v18, v19, v20, v21b4. Confirmed that does NOT happen in v16, v17.
(Reporter)

Comment 1

4 years ago
Also worth noting that we are intending to push a new release for our web application that affects thousands of people, but this release is being held up due to the fact that the new images we need to use cause issues with the latest versions of Firefox.

Comment 2

4 years ago
Bump - this is very big deal effecting our entire user base of over 15,000 medical staff. You'll see some others from our company jump in and vote -- that's not fake folks -- that's urgency. Thanks in advance.

Comment 3

4 years ago
Provide a testcase or image with such a behavior.
Flags: needinfo?(ben.aiken)
Keywords: testcase-wanted
(Reporter)

Comment 4

4 years ago
Created attachment 741841 [details]
Zipped up package with SVG, JPG and page to demonstrate
Flags: needinfo?(ben.aiken)
(Reporter)

Comment 5

4 years ago
The easiest way to reproduce this (and our use case) is when the image is embedded within an SVG. I am attaching a small set of files with a page that demonstrates the issue. The issue is significantly worse in v20.0 of Firefox from what I can tell.
(Reporter)

Updated

4 years ago
Summary: Large scaled images cause choppy scrolling → Large scaled images in SVG's cause choppy scrolling
Version: 18 Branch → 20 Branch
(Reporter)

Comment 6

4 years ago
When loading the same page in the attached package in Safari [Version 6.0.2 (8536.26.17)], there isn't any demonstrable chop.

Comment 7

4 years ago
If this didn't happen in 17 it would be helpful if you could find a regression range. Instructions for how to do that are here: http://mozilla.github.io/mozregression/
(Reporter)

Comment 8

4 years ago
Comment on attachment 741841 [details]
Zipped up package with SVG, JPG and page to demonstrate

This attachment is obsolete. Need to update with a new one. My apologies.
Attachment #741841 - Attachment is obsolete: true
(Reporter)

Comment 9

4 years ago
Created attachment 741870 [details]
Corrected attachment Zip
(Reporter)

Comment 10

4 years ago
Great tool (mozregression). Here are the results - hopefully this should really help narrow it down:

Last good nightly: 2013-01-07
First bad nightly: 2013-01-08

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=605ae260b7c8&tochange=dccab70d8554

Comment 11

4 years ago
Is it still a problem with the latest nightly? Bug 504071 is about the only image thing in that range and I think that was recently disabled for SVG images by bug 861805.
(Reporter)

Comment 12

4 years ago
Yep, unfortunately still seeing it. I tested with the following nightly version: 23.0a1 (2013-04-25).

What about bug 798839? It's related to gradients but I'm wondering if maybe some refactoring occurred related to the SVG piece?
(Reporter)

Comment 13

4 years ago
Or perhaps bug 825834? Seems like a few SVG-related commits happened as part of this changeset: http://hg.mozilla.org/mozilla-central/rev/dccab70d8554

Comment 14

4 years ago
bug 798839 is code that's disabled and you're presumably not using a <view> element in your SVG as they are rarely used. Do correct me if I'm wrong though.
(Reporter)

Comment 15

4 years ago
Hmm okay. I believe you're correct unless the way we're using SVG's inherently uses an SVGViewElement.

Have you or anyone else had a chance to look at the sample code attached and reproduce the issue? I had a few other of our developers confirm the same findings that I did using mozregression with the sample provided.

Comment 16

4 years ago
You could try profiling the 

Last good nightly: 2013-01-07
First bad nightly: 2013-01-08

builds. Perhaps something will jump out. https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler
(Reporter)

Comment 17

4 years ago
Created attachment 742476 [details]
2013-01-08 nightly

Profiler results from 2013-01-08 nightly.
(Reporter)

Comment 18

4 years ago
Created attachment 742477 [details]
2013-01-07 nightly

Profiler results from the 2013-01-07 nightly.
(Reporter)

Comment 19

4 years ago
Profiler results from the two nightlies have been attached. There's a noticeable increase resources being used inside the image::imgFrame::Draw layer. I have highlighted the two comparable areas on the attached images.
(Reporter)

Comment 20

4 years ago
Did the attached profiling images help in determining what the issue is?

Updated

4 years ago
Attachment #741870 - Attachment mime type: application/octet-stream → application/zip

Updated

4 years ago
Component: Untriaged → Graphics
Keywords: perf
Product: Firefox → Core

Updated

4 years ago
Keywords: regression

Comment 21

4 years ago
Any progress on finding the cause of the increased resources?

Comment 22

4 years ago
Can we please fix this ASAP. Thanks,
Alice, can you help identify what caused this? Nothing is jumping out from comment 10.

Comment 24

4 years ago
I am seeing this too. Do we know what code introduced it?

Comment 25

4 years ago
My pc is windows7, And I notice the choppy scrolling.

Steps to Reproduce:
1. Open attachment 741870 [details] ffTest.html
2. Reload skip cache (Ctrl+F5)
3. Scroll mouse wheel to down immediately after completion of the page load
4. Repeat Step.2-3 if necessary 
 
Actual Results:
Smooth scroll fails.

Expected Results:
Smoothly scrolled to down

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/48abe27b73b7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20130106 Firefox/20.0 ID:20130106204602
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/546f9f3999d3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20130106 Firefox/20.0 ID:20130106214802
Pshlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=48abe27b73b7&tochange=546f9f3999d3

Suspected: Bug 504071

Updated

4 years ago
Blocks: 504071
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 26

4 years ago
/begging

We are literally "screwed" without a fix for this. We dropped support for IE and are "all in" for Firefox. We have over 15,000 end users. We were named to Forbes "America's Most Promising Companies." Not that all companies dont have potential, but this silly little bug is really putting an entire company of 135 people in jeopardy.  

Please. Please. Help.

Dan aka "The CEO"

Comment 27

4 years ago
Please fix this.

Comment 28

4 years ago
This is mission critical for our app which is involved in patient care.  Our physicians will not be able to care for their patients effectively without this fix.  Please help
Created attachment 747000 [details]
JPG for testcase
Created attachment 747003 [details]
SVG for testcase
Created attachment 747004 [details]
testcase
Attachment #741870 - Attachment mime type: application/zip → application/java-archive
Note that this testcase could be written without SVG and would probably perform better on all browsers.
Created attachment 747324 [details] [diff] [review]
Propagate FLAG_CLAMP through RasterImage::DrawWithPreDownscaleIfNeeded
Assignee: nobody → roc
Attachment #747324 - Flags: review?(joe)
Thanks Ben Aiken for the profiling!
status-firefox20: --- → wontfix
status-firefox21: --- → affected
status-firefox22: --- → affected
status-firefox23: --- → affected
Keywords: testcase-wanted
Comment on attachment 747324 [details] [diff] [review]
Propagate FLAG_CLAMP through RasterImage::DrawWithPreDownscaleIfNeeded

Review of attachment 747324 [details] [diff] [review]:
-----------------------------------------------------------------

::: image/src/RasterImage.cpp
@@ +3090,5 @@
>                        mSize.height - framerect.YMost(),
>                        framerect.x);
>  
> +  frame->Draw(aContext, aFilter, userSpaceToImageSpace, aFill, padding, subimage,
> +              aFlags & FLAG_CLAMP);

Couldn't we just pass aFlags unmodified through here? (We only look at FLAG_CLAMP now, but in the future we could look at others.)
Attachment #747324 - Flags: review?(joe) → review+
Sure. I'll do that.
Created attachment 747436 [details] [diff] [review]
fix v2
Attachment #747324 - Attachment is obsolete: true
Attachment #747436 - Flags: checkin?
(Reporter)

Comment 38

4 years ago
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #34)
> Thanks Ben Aiken for the profiling!

You bet! Please let me know if there's anything else we can do to help with this.
Attachment #747436 - Flags: checkin? → checkin+
https://hg.mozilla.org/integration/mozilla-inbound/rev/831491563b7d

Comment 40

4 years ago
Thanks for working on this team. It means a great deal.
https://hg.mozilla.org/mozilla-central/rev/831491563b7d
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23

Updated

4 years ago
status-firefox23: affected → fixed

Comment 42

4 years ago
Thank you so much for resolving this issue, much appreciated!

Comment 43

4 years ago
Is the fix going to backport in beta Firefox 21 or is it too late?
It's definitely not going to be in 21, but we may get it into 22.
tracking-firefox22: --- → ?
I've retriggered Nightlies (and cancelled the existing ones) to pick up this change. In a few hours (slightly longer for Windows), the 2013-05-10 Nightly will be available, which will contain this fix. Download it at:
http://nightly.mozilla.org/
(See the about panel to confirm which date nightly you have).

Comment 46

4 years ago
Looking forward to testing this, and we very much appreciate all the hard work in getting this resolved. Since this is not going to get picked up in 21, what's the super high level timeline for 22? The entire team here, and all of our clients, are grateful for getting this resolved.
Roughly June 25th for v22.
Firefox releases ship every 6 weeks. Fx22 (assuming this patch is approved to land there) is scheduled to ship 2013-06-25.
https://wiki.mozilla.org/RapidRelease/Calendar
Instead of waiting for this to get fixed in the stable version of Firefox you may want to work around the issue, comment 32 suggests it shouldn't be too hard.
(Reporter)

Comment 50

4 years ago
(In reply to Timothy Nikkel (:tn) from comment #49)
> Instead of waiting for this to get fixed in the stable version of Firefox
> you may want to work around the issue, comment 32 suggests it shouldn't be
> too hard.

We're using SVG's to overlay additional information on the image, but the problem seems to be related to any large scaled images. In our situation, our large scaled images are JPG's embedded within an SVG. The less the image scales, the less the chop happens. Our images are approximately 6000x6000 pixels to give you an idea of the amount of scaling that has to happen. 

We can actually work around the problem by drastically scaling down our images. However, this isn't by any means an ideal solution for us. Detailed views of the body matter very much in the medical field and scaling down these images really kills the ability for us to show those details.

That being said, this latest change helps the problem, but it actually doesn't fix it for us. There's still a drastically noticeable difference between the performance from v17 vs. the latest nightly. We're still exploring other options as well because we just absolutely need to be able to get around this and still can't launch with the latest nightly's performance.

We really can't stress enough how much we appreciate the efforts and attention that we've been able to garner for this issue, but I don't think we're in a FIXED state yet.

I will work on getting more profiling information for the team to see what else might stand out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
No need to track, please just nominate for uplift approval once resolved.
tracking-firefox22: ? → -

Updated

4 years ago
status-firefox23: fixed → affected

Comment 52

4 years ago
(In reply to Ben Aiken from comment #50)
> There's still a drastically noticeable difference between the performance from v17 > vs. the latest nightly.

The regression appeared in FF20 nightlies, so asking your clients to use Firefox 17 ESR (which is recommended in corporate/university environment) will fix the issue.
See http://www.mozilla.org/en-US/firefox/organizations/
We shouldn't reopen this bug. A bug was fixed here.

Please file a new bug which is a clone of this bug. And I think reprofiling would be very helpful.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
Also, is Mac the only platform you care about?

Updated

4 years ago
status-firefox23: affected → fixed
(Reporter)

Comment 55

4 years ago
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #53)
> We shouldn't reopen this bug. A bug was fixed here.
> 
> Please file a new bug which is a clone of this bug. And I think reprofiling
> would be very helpful.

Will do shortly. Thank you sir.

Also regarding the Mac platform question - nope, we care about both. Our clients are a mix of both Windows/OSX (and possibly even Linux).
Did you file that new bug?

Updated

4 years ago
Flags: needinfo?(ben.aiken)

Comment 57

4 years ago
I guess it's bug 871729.
(Reporter)

Comment 58

4 years ago
Sorry no, not yet. Bug 871729 is separate from this issue. I will be re-profiling for this issue later today and opening up a clone bug for this issue as requested. Thanks for the reminder!
Flags: needinfo?(ben.aiken)
(Reporter)

Comment 59

4 years ago
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #56)
> Did you file that new bug?

Bug 873551 has been created. I am going to note in that ticket, but I'm being blocked from profiling newer builds 2013-01-18 and on seem to have broken profiling, at least for OSX. Confirmed this with another team member.
Keywords: verifyme
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0

Verified as fixed on Firefox 23 beta 9 (buildID: 20130725195523) and latest Nightly (buildID: 20130725171558).
Status: RESOLVED → VERIFIED
status-firefox23: fixed → verified
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.