754644 - Genome Maps is slow

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Scoobidiver (away)]

See https://support.mozilla.org/questions/926540

I see no improvements in the trunk.

Comment 1

[Robert Longson [:longsonr]]

What about it is slow? What do I need to do that demonstrates slowness?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Just loading is somewhat slower than Chrome or me.  So is clicking on the chromosome.

But yes, a clear description of what's slow from the reporter would be _very_ helpful.

I profiled the two actions above, by the way.  Some things to note for the latter:

30% of the time under nsDocument::EnsureCatalogSheet, called from NS_NewSVGElement.  A lot of this seems to be regathering rule processors.  Wonder why.

30% SVG painting.

10% refresh ticks

10% layout/style flushes from getting computed visibility and left styles in the page while there are pending style//layout changes.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I tried the page in a debug build to see why we have so much EnsureCatalogSheet, but it hits JS "too much recursion" exceptions there...  I'd expect this to happen only once per document, so the fat that it shows up in the profile is pretty confusing.

Comment 4

[Boris Zbarsky [:bzbarsky]]

The catalog sheet thing was bug 754894.

With that locally dealt with, the SVG painting time is 60% of total.  About half of this is under PaintFrameWithEffects calling gfxContext::Paint (ending up under CGContextDrawImage), another 15% is PaintFrameWithEffects calling PushGroup, the rest is scattered about.

Comment 5

[Daniel Holbert [:dholbert]]

For the record: genomemaps currently shows me the following in a notification at pageload, discouraging usage of Firefox for viewing the site:

> This release makes an intensive use of new web technologies and standards
> like HTML5 and SVG, so the browsers that are fully supported and will provide
> the best user experience are:
>   Google Chrome 14+
>   Apple Safari 5+
> Other browsers may rise some errors. Firefox11+ works very slow on Linux and
> Windows 7 and the usage it is not recommended. Internet Explorer 9 is not
> supported since they not support many of the features of HTML5,
> Internet Explorer 10 Consumer Preview works fine.

Comment 6

[Jonathan Watt [:jwatt]]

Clicking on the "Karyotype", "Chromosome" and "Region" buttons is incredibly slow for me.

Comment 7

[igmecas]

I'm Nacho, the project manager of Genome Maps.

Boris, just to clarify, the notification pageload was added a few days ago, we were forced to add it as the user experience with Firefox was far from good.

>>But yes, a clear description of what's slow from the reporter would be _very_ >>helpful.
well, I think that when compared to Chrome or Safari it's clear what slow means. There is no a smooth navigation with Firefox, when trying to drag it takes a few seconds, ~2sec depending on machine, to move, while in Chrome and Safari is awesome fast.

Our first impression was that the problem was in SVG rendering, but we do not have real debug done yet.

Comment 8

[Robert Longson [:longsonr]]

It seems there are a number of uses of opacity that likely should be replaced by fill-opacity. That would probably speed things up.

Comment 9

[frasator]

Hi, I'm Paco, a developer of Genome Maps, i created an svg test with 3500 shapes with 1px height just to measure the performance, try to drag the svg over the x axis. Chrome handles it very well, but Firefox is quite slow.

There is the test:

http://bioinfo.cipf.es/apps/svg-stress-test.html

Comment 10

[Jonathan Watt [:jwatt]]

Thanks frasator! I have a partially written patch that I think will help that testcase.

Comment 11

[Jonathan Watt [:jwatt]]

I think my patch for bug 766429 has fixed the issues here, but it would be good to get other's feedback on that. Anyone willing to test the current nightly? The latest builds here are here:

https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

The first builds to have the fix from bug 766429 are here:

https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/06/2012-06-21-03-05-36-mozilla-central/

Comment 12

[Scoobidiver (away)]

igmecas, is it OK for you in Firefox 19?

Comment 13

[igmecas]

Hi,

yes and no, things have improved a lot in Windows, unfortunately FF19+ in Linux (64 bits) still is too slow rendering SVG to be usable.

If you try to just move this URL, from an old Comment, in Linux with Chrome and Firefox you will notice the huge difference immediately:

http://bioinfo.cipf.es/apps/svg-stress-test.html


I really appreciate your efforts, do not hesitate to contact me for any information you need.

Thanks!

Comment 14

[Jonathan Watt [:jwatt]]

Attachment: frasator's reduced testcase

Attaching frasator's testcase just to make sure we don't lose it.

Comment 15

[Jonathan Watt [:jwatt]]

So frasator's reduced testcase creates 3500 <rect> elements, and dragging changes the "x" attribute on all of them.

I profiled the testcase with the very latest SVG performance improvements that I _just_ landed on inbound (i.e. it may be a few days before latest Nightly will show time being spent in the same places).

http://people.mozilla.com/~bgirard/cleopatra/#report=cb8ff627391b974055565d4feedb092de12a1e7d

In that profile over 75% of the samples are in ProcessDisplayItems of which the vast majority is spent in nsRegion::sub (72% of the total samples). Only 17% of the time is actually being spent under LayerManagerOGL::EndTransaction actually doing any painting.

So we very much depend on bug 869505 here.

Comment 16

[Jan Bösenberg]

Is this still slow? I just tried to reproduce this in Firefox 60 on Windows 7, for example by clicking the "Karyotype" button, but it works quite well.

Also the reduced test case does not cause performance problems anymore, it is comparable to Chrome.

Maybe this issue can be closed?

Comment 17

[frasator]

I have tested a modified version of svg-stress-test.html with 70000 elements instead of 3500 and the performance in Chrome 67 and Firefox 60 is apparently the same so yes, it can be closed.