869505 - SVG in Mozilla can be much slower than other implementations due to the overhead of display lists and layers

Status: NEW

(Core :: SVG, defect, P2)

Description

[Jonathan Watt [:jwatt]]

Switching SVG to display lists (bug 614732 et. al.) got us a lot of wins, but we're really hurting on large SVG files. Mozilla is often much slower than other implementations on large SVGs due to spending a lot of time building display lists.

My impression is that display lists generally seem to work well for large HTML documents, presumably because the elements are spread over a large scrollable area which means that only a relatively small number are ever on the screen at once. (I.e. only a relatively small number of display list items need to be created at any point in time.) This doesn't generally hold for large SVG files though, since usually _all_ the elements in the document are on-screen at the same time.

Comment 1

[Chris Lord [:cwiiis]]

I guess we can tackle this by either making display-list building faster (which would benefit everything) or caching svg display lists (they already have their own invalidation code, right? Or wrong?) - or some other option...

When I last looked, it seemed that calculating the clip items was most of the work when processing display lists, but maybe I misread some details/I remember incorrectly - I'm not sure if it's really possible to cache the processing information (I looked and every idea I had broke dlbi in some way), but it may be possible to cache the clip regions and save doing the transforms to recalculate them every time display items are processed?

Would be good to get some layout people to comment on this I think...

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Clip handling should have sped up significantly with bug 841192. But I don't think it's likely to be much of an issue with SVG.

I think we should try to profile display list construction for large SVG documents and see what can be done to speed it up.

Retaining display list data between paints is theoretically possible but would be complex, so a last resort.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 17 votes.
:jwatt, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 4

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.