772152 - Optimize nsSVGFE::ComputeChangeBBox() overrides for better filter performance

Status: NEW

(Core :: SVG, defect)

Description

[Jonathan Watt [:jwatt]]

Now that bug 738192 is fixed (now that we no longer invalidate the entire SVG viewport if there's a filter along the parent chain of a changed SVG element) we need to improve other aspects of the filter code. One of the areas in need of work is the nsSVGFE::ComputeChangeBBox overrides. When a small part (e.g. a descendant element) of a filtered element changes, we can end up invalidating the entire filtered element because some of these overrides do a poor job. For example, the overrides for nsSVGFEConvolveMatrixElement, nsSVGFELightingElement and nsSVGFEDisplacementMapElement invalidate the maximal affected area.

Comment 1

[Jonathan Watt [:jwatt]]

Attachment: testcase

For me, Opera is much faster than us on this testcase, but interestingly Chrome is over twice as slow.

Comment 2

[Jonathan Watt [:jwatt]]

roc, bz: I'd like to turn that testcase into a Talos test at some point, so I'd be interested in your feedback on the method of testing it uses, and how I should fix or improve it for Talos.

Comment 3

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

I don't know how to test this. This kind of spot performance testing seems really hard.

I don't think we should work on this bug anytime soon. The key to improving filter performance is mostly to move filters to the layer system and use GPU acceleration for them. I am actually eager to have someone work on that, but it depends on SVG display lists and some layers refactoring that is going on.

Comment 4

[Jonathan Watt [:jwatt]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #3)
> I don't know how to test this. This kind of spot performance testing seems
> really hard.

The test is just "how many fps can we get", or something like that, and is pretty much what the test does already. I'm not sure what's hard. I was wondering about the use of setInterval, for example, and whether that's not a good thing to use.

> I don't think we should work on this bug anytime soon. The key to improving
> filter performance is mostly to move filters to the layer system and use GPU
> acceleration for them.

Moving filters to the layers system won't help with the particular problem described here, since the issue is "we repaint the entire filtered element". Using the GPU to speed up filter painting would help.

> I am actually eager to have someone work on that, but
> it depends on SVG display lists and some layers refactoring that is going on.

Agreed that layers caching and GPU acceleration are more important. The latter is also a fair bit more challenging to fix than this bug.

Comment 5

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

(In reply to Jonathan Watt [:jwatt] from comment #4)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #3)
> > I don't know how to test this. This kind of spot performance testing seems
> > really hard.
> 
> The test is just "how many fps can we get", or something like that, and is
> pretty much what the test does already. I'm not sure what's hard. I was
> wondering about the use of setInterval, for example, and whether that's not
> a good thing to use.

The problem is that there are thousands of similar tests we'd like to have, and we simply can't run that many performance tests.