I wonder how different browsers rasterize tiling SVG backgrounds. Ideally they should rasterize it once to a buffer and then just blit it a bunch of times. But if any browser tries to rasterize it every repetition that's a ton of vector drawing for some of those patterns and it may be hella slow on some device/browser combinations.
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.
+1 for zoom. The only other way to do it would be using pseudo elements and scaling it—or something or other. But offering zoom on this site would be nice :-)
Hey! I'm a friend of Steve (who created Hero Patterns) and built the interactive VueJS stuff for the site.
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.
A long time ago, I figured I'd save bandwidth by making the background image a single pixel (don't ask why I didn't just set the background color, I don't have a good reason). That was back in the days when web designers tried to make their pages less than 15k.
The rendering of the image on the background in Netscape was so slow, you could see it draw the lines across the screen.
:) I encountered that with 2x2 gifs, two diagonal black against two alpha, to make a darkening half tone. Looked ok visually, but boy did it sieze browsers up!
> If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.
> 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.
Yes. Use is simply that. You use it and don't modify it.
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).
