timing of gradients in SVG browsers
- Some of you may be familiar with the thing I showed in Tokyo for timing DOM insertions of different kinds of content into the browsers:
basic objects, with and without transparency, clipPaths, filters, translations etc.
For a problem that JD Benamou and I have been discussing (see description later if you're interested), I have extended that timing "chamber" so that it now includes linear gradients.
The fill options provided are 1. simple fill 2. a single random linear gradient reused by all elements or 3. a customized linear gradient -- one for each object.
Interestingly, in IE/ASV and Opera 9.23 the time to create separate gradients for each of several objects appears to be almost negligible.
That is, I used the above chamber to create 200 rectangles or triangular paths iteratively (redrawing the DOM with window.setTimeout between each new construction). The objects were either filled with a random color or with their own randomly constructed linear gradients having random colors and random orientation. Providing each with a separate gradient took no more time in rectangles than to simply fill with a monochrome fill.
In path objects, customized linear gradients per object took only a hint of more time in IE and Opera than to fill each with the same gradient or to fill each with random monochrome paint.
In Safari (3 beta for Windows), the time to render <rect>'s was unaffected by whether the fill was a color or a lineargradient, though with the <path> tag time increased almost fourfold for the custom gradients.
Firefox rendering seemed most affected by the custom rendering with twice as much time or so required to render custom gradients for <rect> and about six times as much for <path>.
In essence, if we were to control this experiment more precisely, we might expect to see a significant threeway browser by type of gradient by type of object interaction based on these rather cursory analyses on just a single machine.
All in all, it looks as though creating linear gradients is not much more expensive than creating monochromatic fills (at least for
IE and Opera) and this tells us something useful for building simulated mesh gradients.
Well, some of you may recall discussion about gradients other than linear and radial, here over the past few years. JD and I have a shared interest in using gradients which might smoothly tile a mesh grid for modeling systems of partial differential equations. Such gradients might be neither radial nor linear, but might, instead, parallel (or converge) along a nonlinear path, for example. While one could stitch together piecewise linear gradient components into a triangularization of the plane such that the function (or surface) defined over the 2D grid would be continuous, the first order derivatives of those pieces (namely the angles at which the gradients meet) would not appear smooth. How then to allow the slopes of the gradients to match up at the boundaries of the triangles?
Well, one thing we considered was building a series of monochromatic regions (<path>s) whose union would equal a given triangle and then choosing the fill colors so that the "mesh-gradient" would be simulated with a series of tiny svg objects. Another approach would be to stitch together slightly larger subregions consisting of linear, or radial gradients instead of monochromatic fills to simulate the desired gradient. On the basis of this experiment it would appear that we cannot rule out the use of piecewise linear gradients to approximate nonlinear ones, merely on the basis of time constraints (that we both rather expected) for actually rendering the gradients in SVG.
[Non-text portions of this message have been removed]