Jon was right:
"Then there's the size in memory that's needed for the full string node in the DOM tree, plus all the UI impact from having large strings kicking around, including the XML Editor window."
The UberConverter is somewhat stuck creating embedded images because it is running on pipes, has to extracted embedded images from other formats, and I haven't layered 800 options onto it yet. This gave me a chance to play with inkscape during the debugging and the XML editor really crawls (this machine is getting old, but it's still dual AMD 2400's w/ 2GB ram.)
I also noticed that if I save the svg out of inkscape, the linebreaks in the base64 data go away and gvim gets really mad, so there are a few issues to consider in any upcoming embedded image work on inkscape.
http://scratchcomputing.com/tmp/bitmapfills.svgz
I'm sure there's a way to do this better using <use> elements or something (particularly in this example, which has two instances of one image.) I'm just following the example from the embed_raster_in_svg.pl script for now. Suggestions welcome.
--Eric
Eric Wilhelm wrote:
I also noticed that if I save the svg out of inkscape, the linebreaks in the base64 data go away and gvim gets really mad, so there are a few issues to consider in any upcoming embedded image work on inkscape.
Not only vim: the data structure to store text commonly used by text editors is not very usable with very long lines... :)
participants (2)
-
Emanuele Aina
-
Eric Wilhelm