407898 - UI freeze when loading SVG

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Benoît Dejean]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

I'm using firefox to access the IBM WAS Console. It has a performance chart which auto-refreshes every 5s. The chart is a SVG file. When the refresh takes place, firefox freezes for 1s.

Reproducible: Always

Comment 1

[Robert Longson [:longsonr]]

Does this happen in a nightly build i.e. this... http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ ? 

If so can you add the SVG as an attachment to this bug please?

Comment 2

[Benoît Dejean]

Will that mess with my current settings ?
(Anyway, it's seriously broken, because if i runas the nightly as a different user, it opens a window of the firefox used by the current user)

Comment 3

[Benoît Dejean]

Attachment: zipped SVG chart

Opening this SVG standalone brings the same behaviour: firefox freezes for 1-2s.

Comment 4

[Robert Longson [:longsonr]]

It doesn't freeze under the latest trunk. Fixed by check in for bug 18333.

Comment 5

[Benoît Dejean]

With latest trunk, the situation has improved a bit. The UI does not freezes as long as in 2.0. My test is:
- drag & drop the svg file in a tab
- right click again and again in the toolbar to pop a menu.

Now it freezes for less than a second.

But when i browse the full page, the freeze is still very important and make my experience very poor.

Comment 6

[Benoît Dejean]

I would roughly said that UI freezes somewhere about 0.7s. But as the other elements of the page are heavy (javascript), the overall freeze time is about the same.

Comment 7

[Robert Longson [:longsonr]]

Your "test" file is 433kb. It is unrealistic to expect it to be instant isn't it?

Comment 8

[Benoît Dejean]

I don't expect to be instant.

But i don't get why it has to freeze the UI ?
- If i'm in a different tab, whenever the graph tab refreshes, i get stuck.
- If i'm in the graph tab, which displays the graph and statistics, when the UI freezes on refresh, this blocks my scrolling, etc

Comment 9

[Benoît Dejean]

Can you please reopen it ?

Comment 10

[Robert Longson [:longsonr]]

If you wish, although I wouldn't hold my breath for anyone to write a miraculous patch to make a 433kb file display instantly.

Comment 11

[Benoît Dejean]

This bug has nothing to do with loading instantly a SVG file. It's about not totally freezing firefox while loading it. I use a dual-screen, and it's really painful to get stuck on a screen while the other is refreshing.

Comment 12

[Robert Longson [:longsonr]]

You want multi-threading of the UI tabs then.

Comment 13

[Adam Kowalczyk]

Robert, bug 40848 WONTFIX-ed the idea of per docshell threading. It didn't WONTFIX increasing UI responsiveness as a whole, but just one of the possible solutions to it. This bug is far too different from bug 40848 to be marked as duplicate, IMHO.

In any case, UI freezing is a legitimate bug. I think this bug should be reopened.

Comment 14

[Brendan Eich [:brendan]]

Adam's spot on. Please do not take a premature implementation proposal for a bug symptom. Bugs start out as symptoms often, unless a developer is filing more of an implementation work item. There are several SVG implementations that do not use threads, yet do not starve the UI.

/be

Comment 15

[mmortal03]

I see this after clicking on the E8 image at the following link: http://en.wikipedia.org/wiki/Image:E8_graph.svg

Comment 16

[Ben Bucksch (:BenB)]

I think the bug reported is valid. The initial description does not prescribe a solution, but an actual, observable problem. As such, I CONFIRM this bug. It's not a dup of bug 40848, but a part of bug 384323.

Comment 17

[heraldo]

I'm getting a permanent freeze in Firefox 5 opening this large svg file, is this the same issue? http://upload.wikimedia.org/wikipedia/commons/d/df/Karte_Metropolregionen.svg

Comment 18

[Robert Longson [:longsonr]]

(In reply to comment #17)
> I'm getting a permanent freeze in Firefox 5 opening this large svg file, is
> this the same issue?
> http://upload.wikimedia.org/wikipedia/commons/d/df/Karte_Metropolregionen.svg

Best if you create a new bug. We can always make it a duplicate later if we find the underlying cause is the same.

Comment 19

[(dormant account)]

Daniel, do you think this is a common enough problem to be tracked for snappy project? Is it possible that smaller/simpler SVGs also cause annoying stalls? Is this something that we can easily add telemetry probes for?

Comment 20

[Daniel Holbert [:dholbert]]

I'm not aware of ways for small/simple SVG to create annoying stalls, off the top of my head.   FWIW, the attached testcase loads in about ~2 seconds for me. (though I have a reasonably powerful laptop)

From a quick sysprof profile, it looks like we spend 35% of our time in nsRefreshDriver::Notify's FlushPendingNotifications call (which is all restyle-processing), and 20% of our time running (synchronous) JavaScript inside the "onload" handler,  nsHtml5SVGLoadDispatcher::Run

It's possible that a lot of the pending notifications may *come from* the onload script, too.

If I drop the onload handler entirely, the pageload time is reduced substantially (from ~2 sec to ~1 sec), on my machine.

So I think this is (at least in part) an instance of "synchronous script execution can hang the UI", which isn't really SVG-specific at all.

Comment 21

[Daniel Holbert [:dholbert]]

(In reply to Taras Glek (:taras) from comment #19)
> Daniel, do you think this is a common enough problem to be tracked for
> snappy project?

There isn't just one "this" here -- from my experience in comment 20, the hottest code is from (a) flushing retyles, and (b) running synchronous script from the page (which may in part trigger 'a').

But -- I could see slowness from frequent/long restyle-flushes being a common enough problem to be tracked for the snappy project, yeah. (This may be worse in SVG, I'm not sure.)  dbaron or bz would be worth asking about that, too.

> Is this something that we can easily add telemetry probes for?

(I'm taking "this" to mean slowness from restyle-flushes)

I've not yet added a telemetry probe, so I'm not sure what's involved there or what would make it easy.  But I think it'd be pretty easy to get a timestamp before and after we flush restyles, so we could look at the distribution of the flush-durations (since that's time spent away from the event loop).  That'd probably be worth doing.

Comment 22

[(dormant account)]

1-2 seconds is a lot. Adding telemetry probes is easy, fun and educational, can I'll spin off a bug for that.

Comment 23

[Daniel Holbert [:dholbert]]

Attachment: SVG chart

(bugzilla's attachment size-limits have been relaxed since this bug was filed; attaching already-extracted testcase, for convenience)

Comment 24

[Daniel Holbert [:dholbert]]

Attachment: SVG chart w/ onload removed

(In reply to Daniel Holbert [:dholbert] from comment #20)
> If I drop the onload handler entirely, the pageload time is reduced
> substantially (from ~2 sec to ~1 sec), on my machine.

For reference, here's the same SVG chart testcase, but with 'onload' dropped.

Comment 25

[Jonathan Watt [:jwatt]]

On Mac it doesn't seem like our rendering speed in much different to Chrome or Opera. Are we much slower on Windows or something?

Comment 26

[Robert Longson [:longsonr]]

No, we're pretty much the same as Opera on Windows on Firefox 11.

Comment 27

[Jonathan Watt [:jwatt]]

Okay, let's close this as WORKSFORME then.

In case anyone's interested I span off bug 876190 and bug 876192 based on the discussion above.