On Tue, 08 Feb 2011 20:57:03 +0100, gb_n_svg <[email protected]> wrote:
> I have been experimenting with SVG Filters across Safari, Firefox,
> Chrome and Opera.
>
> I am trying to get some stable performance timing so that I can
> understand which filters are pretty quick, and which aren't. (I'd also
> like to do these as browsers are improved)
One general rule of thumb for filters: the larger the area you filter is
the heavier it will be to compute.
Certain filters are faster than others, most depend heavily on what the
attribute values are (e.g for feConvolveMatrix a larger matrix means more
calculations per pixel).
These filters are usually heavier than the others:
- feGaussianBlur (if the area to blur is large and/or 'stdDeviation' is
large. This primitive is one of the ones that is most likely optimized in
browsers, for the normal cases at least.)
- feDisplacementMap
- feTurbulence (if 'numOctaves' is large)
- feConvolveMatrix (if 'order' is large)
- the lighting filters
> There are a couple of obstacles:
> 1. Some stuff is so quick, it can't be reliable measured
> 2. Some browsers schedule drawing differently, so aren't actually timed
>
> My approach to solve 1 (to make stuff easy to measure) is to run a
> JavaScript function to create hundreds of instances of a group, with the
> filter applied to each of the groups. This seems to be enough that
> timing is relatively useful.
>
> e.g.
> function () {
> var startTime = new Date();
> ... do the create and rendering for hundreds of groups ...
> var endTime = new Date();
> ... calculate elapsed time and print it ...
> }
The rendering isn't necessarily synchronous, and most likely won't happen
in the midst of running a function like this. A repaint is commonly
requested on completing a javascript "thread", essentially what happens
when the function called from the timer returns.
If you add a timer and call some function regularly then you can get a
rough idea of the framerate, but note that implementations that skip
rendering frames would be favored by that. Some implementations may
throttle the framerate to get less jerky animations, or limit the rate of
updates to avoid using too much resources.
For Opera, we added SVGSVGElement.currentFps, which returns a floating
point number representing the current framerate. It should be more
accurate than going by the timer method. We also added
SVGSVGElement.targetFps, which you can use to set the target framerate for
SMIL animations, set it high to strive for a higher framerate, set it low
to conserve resources. An example of how that can be used:
http://dev.opera.com/articles/view/presto-2-2-and-opera-10-a-first-look/#fps.
Note that the example there changes the text in the svg once every 100ms
so the lowest framerate that will be reported is going to be around 10
(100ms timer = 10 updates per second).
Hope this helps
/Erik
--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
------------------------------------
-----
To unsubscribe send a message to: [email protected]
-or-
visit http://groups.yahoo.com/group/svg-developers and click "edit my
membership"
----Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/svg-developers/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/svg-developers/join
(Yahoo! ID required)
<*> To change settings via email:
[email protected]
[email protected]
<*> To unsubscribe from this group, send an email to:
[email protected]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
