It's not immediately clear that they would do the smart thing because most times SVGs are rendered only once so you would want to render it directly. It's only tiling backgrounds where this optimization makes sense. But I think as a consequence of it being treated as an image in CSS rather than a DOM SVG element it's quite likely most browsers do render it to a buffer first, not as an optimization but just because they treat rasterizing an SVG just like decoding a PNG.
If nobody has noticed these being super slow I guess browsers are doing the smart thing.
We did try a scale/zoom thing initially, but found it wasn't super bullet proof because the patterns are designed at specific pixel sizes and sometimes seams would become visible when tiling the patterns if you scaled by an amount that caused little micro rounding issues with the rendered SVG.
Might take another stab at it, agreed it would be great to have.
The rendering of the image on the background in Netscape was so slow, you could see it draw the lines across the screen.
> build upon the material
Is there clearly defined difference between "build upon the material" and "using the material as part of your project"? Commercial use in most cases involves not wanting to release your own project under CC BY-SA 4.0. Even though it's possible to combine both (commercial use and CC BY-SA 4.0 for your own product), it's highly unlikely.
If your 'use' is more than copy & paste, you've probably crossed the line into the 'remix, transform, or build upon the material' line and need to distribute your versions of these things under the same license.
This doesn't mean your entire product needs to be under the license, only the derivative part(s).