- From: Johannes Roessel <johannes.roessel@uni-rostock.de>
- Date: Tue, 15 Feb 2011 22:45:25 +0100
- To: "www-svg@w3.org" <www-svg@w3.org>
- Message-ID: <B725B6C6CEDC334FBB407CB2F1D9BE58012C8F15814D@MAILSTORE.uni-rostock.de>
Hello, quite a while ago I created a few SVG images for Wikimedia Commons showing a Sierpinski carpet in various generations (up to 6 on commons, I think, although I created up to 7 for myself – they are attached). They start out innocent enough with generation 0: <svg xmlns="http://www.w3.org/2000/svg" version="1.0" width="900" height="900"> <rect fill="#fff" width="900" height="900"/> </svg> By generation 2 I was defining a ninth of the image as a symbol and re-used it to draw the complete image: <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.0" width="900" height="900"> <defs> <symbol id="s" viewBox="0 0 3 3"> <rect fill="#000" width="1" height="1" x="1" y="1"/> </symbol> </defs> <rect width="900" height="900" fill="#fff"/> <use xlink:href="#s" x="0" y="0" width="900" height="900"/> <use xlink:href="#s" x="0" y="0" width="300" height="300"/> ... </svg> And from then on it nests a bit: <?xml version="1.0" standalone="no"?> <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.0" width="900" height="900"> <defs> <symbol id="s" viewBox="0 0 3 3"> <rect fill="#000" width="1" height="1" x="1" y="1"/> </symbol> <symbol id="s1" viewBox="0 0 900 900"> <use xlink:href="#s" x="0" y="0" width="900" height="900"/> <use xlink:href="#s" x="0" y="0" width="300" height="300"/> ... </symbol> </defs> <rect width="900" height="900" fill="#fff"/> <use xlink:href="#s" x="0" y="0" width="900" height="900"/> <use xlink:href="#s1" x="0" y="0" width="300" height="300"/> ... </svg> Now, the problem is this: Generation 5 displays fine in most browsers (except for Webkit browsers) but generation 6 often takes a quite long time and loads of memory (except for Webkit again, which simply crashes). And I don't think I have seen generation 7 anywhere so far. Of course, the files could simply be described with a less deep <use> tree or just specify each individual shape directly, or just a giant path. Obviously the way I've written those files might be easy enough to write but is painful to everyone trying to view them. And I guess this is probably not the kind of file that drawing programs emit so there might not even be an incentive to not crash the browser or the system on attempting to render them. But maybe they could serve as a test case to improve performance and memory consumption in such cases. But mayhaps I'm totally misguided in seeing a slight problem with the implementations here (on that note, though, Wikimedia Commons is able to generate PNG previews, but that's probably due to plenty of time and memory). Regards, Johannes
Attachments
- image/svg+xml attachment: Sierpinski_carpet_0.svg
- image/svg+xml attachment: Sierpinski_carpet_1.svg
- image/svg+xml attachment: Sierpinski_carpet_2.svg
- image/svg+xml attachment: Sierpinski_carpet_4.svg
- image/svg+xml attachment: Sierpinski_carpet_5.svg
- image/svg+xml attachment: Sierpinski_carpet_6.svg
- image/svg+xml attachment: Sierpinski_carpet_7.svg
Received on Tuesday, 15 February 2011 21:46:01 UTC