Closed
Bug 865546
Opened 11 years ago
Closed 11 years ago
Large scaled images in SVG's cause choppy scrolling
Categories
(Core :: Graphics, defect)
Tracking
()
VERIFIED
FIXED
mozilla23
People
(Reporter: ben.aiken, Assigned: roc)
References
Details
(Keywords: perf, regression)
Attachments
(7 files, 2 obsolete files)
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.
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•11 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.
Provide a testcase or image with such a behavior.
Flags: needinfo?(ben.aiken)
Keywords: testcase-wanted
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.
Summary: Large scaled images cause choppy scrolling → Large scaled images in SVG's cause choppy scrolling
Version: 18 Branch → 20 Branch
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•11 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/
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 10•11 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•11 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•11 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•11 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•11 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•11 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•11 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•11 years ago
|
||
Profiler results from 2013-01-08 nightly.
Reporter | ||
Comment 18•11 years ago
|
||
Profiler results from the 2013-01-07 nightly.
Reporter | ||
Comment 19•11 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•11 years ago
|
||
Did the attached profiling images help in determining what the issue is?
Updated•11 years ago
|
Attachment #741870 -
Attachment mime type: application/octet-stream → application/zip
Updated•11 years ago
|
Keywords: regression
Comment 21•11 years ago
|
||
Any progress on finding the cause of the increased resources?
Comment 22•11 years ago
|
||
Can we please fix this ASAP. Thanks,
Comment 23•11 years ago
|
||
Alice, can you help identify what caused this? Nothing is jumping out from comment 10.
Comment 24•11 years ago
|
||
I am seeing this too. Do we know what code introduced it?
Comment 25•11 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•11 years ago
|
Comment 26•11 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•11 years ago
|
||
Please fix this.
Comment 28•11 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
Comment 29•11 years ago
|
||
Comment 30•11 years ago
|
||
Comment 31•11 years ago
|
||
Assignee | ||
Updated•11 years ago
|
Attachment #741870 -
Attachment mime type: application/zip → application/java-archive
Assignee | ||
Comment 32•11 years ago
|
||
Note that this testcase could be written without SVG and would probably perform better on all browsers.
Assignee | ||
Comment 33•11 years ago
|
||
Assignee: nobody → roc
Attachment #747324 -
Flags: review?(joe)
Assignee | ||
Comment 34•11 years ago
|
||
Thanks Ben Aiken for the profiling!
Updated•11 years ago
|
status-firefox20:
--- → wontfix
status-firefox21:
--- → affected
status-firefox22:
--- → affected
status-firefox23:
--- → affected
Keywords: testcase-wanted
Comment 35•11 years ago
|
||
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+
Assignee | ||
Comment 36•11 years ago
|
||
Sure. I'll do that.
Assignee | ||
Comment 37•11 years ago
|
||
Attachment #747324 -
Attachment is obsolete: true
Attachment #747436 -
Flags: checkin?
Reporter | ||
Comment 38•11 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.
Updated•11 years ago
|
Attachment #747436 -
Flags: checkin? → checkin+
Comment 39•11 years ago
|
||
Comment 40•11 years ago
|
||
Thanks for working on this team. It means a great deal.
Comment 41•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
Updated•11 years ago
|
Comment 42•11 years ago
|
||
Thank you so much for resolving this issue, much appreciated!
Comment 43•11 years ago
|
||
Is the fix going to backport in beta Firefox 21 or is it too late?
Comment 44•11 years ago
|
||
It's definitely not going to be in 21, but we may get it into 22.
tracking-firefox22:
--- → ?
Comment 45•11 years ago
|
||
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•11 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.
Comment 47•11 years ago
|
||
Roughly June 25th for v22.
Comment 48•11 years ago
|
||
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
Comment 49•11 years ago
|
||
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•11 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 → ---
Updated•11 years ago
|
Comment 52•11 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/
Assignee | ||
Comment 53•11 years ago
|
||
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
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 54•11 years ago
|
||
Also, is Mac the only platform you care about?
Updated•11 years ago
|
Reporter | ||
Comment 55•11 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).
Assignee | ||
Comment 56•11 years ago
|
||
Did you file that new bug?
Updated•11 years ago
|
Flags: needinfo?(ben.aiken)
Comment 57•11 years ago
|
||
I guess it's bug 871729.
Reporter | ||
Comment 58•11 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•11 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.
Comment 60•11 years ago
|
||
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).
You need to log in
before you can comment on or make changes to this bug.
Description
•