483868 - Firefox much less responsive than Chrome while scrolling/enlarging SVG map with filters

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Max]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7

Firefox appears to get lost when viewing an enlarged svg file. Firefox consumes 100% cpu, not limited by free RAM or disk space. Cannot procede, must Force Quit.

Reproducible: Always

Steps to Reproduce:
1. Go to http://en.wikipedia.org/wiki/File:Hawaii_Island_topographic_map-en.svg
2. Click on map to enlarge.
3. Try to scroll (or anything else).
Actual Results:  
Firefox is frozen, shows "beachball" indicating unresponsive to os.

Expected Results:  
Scroll map.

Comment 1

[Robert Longson [:longsonr]]

Works fine for me, although I'm on Windows.

Does this happen in safe mode? With a new profile?

Comment 2

[Max]

Yes, the same thing happens in safe mode or with a new profile.

Comment 3

[Kurt Weinschenker]

Seeing this happen with a recent nightly Camino (2.0b3pre (1.9.0.8pre 2009031706)) build running under PPC Mac OS 10.4.11.  

Not sure if Camino's trying to calculate something it can't display, or if some program bit's stuck in a loop.  I grabbed a sample with Activity Monitor, and will attach it shortly.

Comment 4

[Kurt Weinschenker]

Attachment: Activity Monitor sample of Camino from above URL

Comment 5

[Robert Longson [:longsonr]]

I didn't realise that the svg file isn't on the URL pointed at, you have to take the svg link on that page.

The file is 
a) huge
b) filled with gaussian blur filters

It works much better on the trunk where it takes about 60 seconds to display due to incremental rendering and then about 7 seconds to activate the tab after that i.e. do a single repaint.

I suggest you download a recent trunk nightly so see the difference.

I'm not sure there's that much more we can do on the trunk. Big files with lots of filters are going to take time to render. Maybe we could adjust how often we do incremental rendering to be based on how long the page takes to redraw.

Comment 6

[Kurt Weinschenker]

Robert, 

First, my bad, I should have clarified that one had to take the link to the SVG on the given URL to display this behavior.

Second, in Camino-land, the build I tested's about as recent as we can obtain.  (No, we won't discuss here some intramural squabbling concerning Gecko 1.9 features between the Camino & FF teams.)

And yes, I waited about five minutes before force-quitting Camino, right after I grabbed the Activity Monitor sample.  Short of shifting over to FF (which I would prefer not to do), the SPOD on that particular SVG is what PPC Camino users might expect.

Comment 7

[Wayne Mery (:wsmwk)]

do you see this today with version 3.6 or on trunk?

Comment 8

[Max]

On 3.6.8 (and in my normal operating mode, not in safe mode), I was able to view the svg image. The response was slow and there were lots of beach balls, but Firefox always completed scaling and panning eventually.

Comment 9

[Jonathan Watt [:jwatt]]

Over 80% of the time is spent under nsSVGFilterFrame::PaintFilteredFrame.

Comment 10

[Jonathan Watt [:jwatt]]

While Chrome checkerboards it is much more responsive, presumably partly due to tiling its rendering. We on the other hand don't seem to be tiling, although we don't particularly seem to be over invalidating.

If I delete the filters from the DOM then perf seems okay.

Comment 11

[Jonathan Watt [:jwatt]]

Ugh, and with e10s turned on things appear to get even worse. APZ allows responsive scrolling, but without painting the offscreen areas that are panned into view. Because the scrolling is responsive it's easy to two finger scroll more in the hope of "freeing" the frozen rendering. But it seems like the longer I scroll about, the longer it is between when I stop and when the page actually re-renders. Kats, you may want to take a look at why that is. It looks like we may be creating a queue of rendering tasks which we complete but then throw away, only using the final one? Or something?

Comment 12

[Kartikaya Gupta (email:[e-mail])]

(In reply to Jonathan Watt [:jwatt] from comment #11)
> Kats, you may want to take a look at
> why that is. It looks like we may be creating a queue of rendering tasks
> which we complete but then throw away, only using the final one? Or
> something?

So what's supposed to happen here is that the APZ sends repaint requests over to gecko pretty frequently, and then on the gecko side, when we're about to do a paint, we check the messages waiting in the IPC queue [1] and update the area to paint based on the most recently received message. That way we should effectively be coalescing the repaint requests.

I added some logging and confirmed that this is happening as intended (i.e. it's not grossly broken). However I do see that we seem to do one extra paint with the wrong displayport at some point. I'm trying to chase it down.

[1] http://searchfox.org/mozilla-central/rev/557f236c19730116d3bf53c0deef36362cafafcd/layout/base/nsRefreshDriver.cpp#1819

Comment 13

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #12)
> However I do see that we seem to do one extra
> paint with the wrong displayport at some point. I'm trying to chase it down.

I don't think this is a bug either, I just had wrong expectations. When the displayport first shifts we do a paint, and that paint taking a while is what queues up the next lot of repaint requests. So when we do the *next* paint is when we run the PeekMessages code to peek ahead, and that second paint is done in the right spot. However while the second paint is happening the user is going to be seeing the results from the first paint, which is obviously delayed relative to where the user's APZ scroll position is.

So in summary this is working as intended from the APZ point of view. Options to improve this behaviour are (1) make painting faster, or (2) delay that first paint a little bit until we have a better idea of where the user is going to go, which seems pretty hard.

(In reply to Jonathan Watt [:jwatt] from comment #11)
> But it
> seems like the longer I scroll about, the longer it is between when I stop
> and when the page actually re-renders.

I'm not really seeing this behaviour, and my logging doesn't indicate it happening either. It seems to be roughly constant from when I stop scrolling to when the page does its re-render.

Comment 14

[Jonathan Watt [:jwatt]]

Per IRC discussion with you, I'm seeing much worse performance. I'll need to investigate.

Comment 15

[Jonathan Watt [:jwatt]]

Apparently that's not going to happen any time soon.

Comment 16

[Robert Longson [:longsonr]]

Seems OK now, nothing like the 60 second delays of comment 5.