See test file: the object initially displayed uses a filter. If you click on it, it is moved across the viewport by means of a small script. Then, more objects containing filters are displayed, and the same movement is applied again. The movement visibly slows down: nominally each move takes not much more than 0.2s, but the third move needs more than 1.5s on my computer. Filter regions are restricted to a region a bit larger than the viewbox of the filtered object, but small enough never to overlap, so there is no need to repaint any of the other objects. Note that the objects are all cloned via <use>, so it looks like the filters are applied for each use element individually. (The same happens if you use a SMIL animation instead.) Hardware: Pentium Dual Core E5300 2.6GHz & Intel G41 chipset

Confirmed against Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110718 Firefox/8.0a1 ID:20110718030807 Opera Next/GC 14 behave as expected.

We repaint everything when something moves. Display lists should most likely fix it.

Is this still an issue in Firefox 13?

And if it is, is it still a problem in latest trunk?: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ Hopefully not, since there have been a bunch of perf improvements recently.

For me (with D2D/D3D10 on) the third Step is almost on par with Opera/Chrome now. Definitely a huge Improvement comparing to Firefox 8.

The effect is less pronounced in 13, but still visible. The third move is around 1s on the same hardware as the original report. It is still possible to thwart painting times by adding more objects with filter effects. In Nightly (16.0a1) the behaviour has changed. It seems only filters on top of other objects with filters contribute to the slowing down, and you need to have a lot of those: ten feSpecularLighting in one place, for example.

Thanks, guys, that's helpful. XtC4UaLL: you're testing with nightly, I presume? ccprog: how does nightly compare with Opera/Chrome for you on your hardware? Also, would you be able to test the following slightly older nightly in particular, and report on how that compares with other versions: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/07/2012-07-06-07-51-26-mozilla-central/

(In reply to Jonathan Watt [:jwatt] from comment #7) > XtC4UaLL: you're testing with nightly, I presume? Yes > Also, would you be able to test the following slightly older nightly in > particular, and report on how that compares with other versions: > > https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/07/2012-07-06- > 07-51-26-mozilla-central/ I did a "Progression" Range Search: Last good nightly: 2012-06-24 (i.e. slow) First bad nightly: 2012-06-25 (i.e. fast) Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e23e10a4638b&tochange=ec9451e9e830 => likely fixed/improved by Bug 738192 (more than Bug 771795 did apparently).

> ccprog: how does nightly compare with Opera/Chrome for you on your hardware? > For the testcase, Opera is slightly faster. In the case of a more complex application, I see a lot of different paces; I can't yet get a clear picture what is the defining factor: nature of the filters, overlap, even colors? - Sometimes Opera slows down almost to a stop, sometimes Nightly. (If you're feeling really ambitious, getting this app to run smoothly might be a good challenge)

Seems to work now. Tested with Firefox 16.