Re: SVG printing performance

Hi Daniel,


> The times I'm getting are still orders of magnitude lower than the
> values you're reporting, though... Maybe you could try printing to a
> file to reduce the number of variables?

Well, I did test printing to a real printer and to a PDF printer, both
showing the same symptom. On a deeper look at the settings, both were
set to 600 dpi so this sounded like a possible variable. Testing again
with another nightly [1] (just updated) and with various settings
measured:
 1. 600 dpi + color = 1'31'';
 2. 600 dpi + black&white = 1'32'';
 3. 300 dpi + color = 1'10'';
 4. 150 dpi + color = 6'';
 5. 600 dpi + color + pages(1-5, mostly text) = 4'';
 6. 600 dpi + color + pages(6, world maps) = 1'28'';
 7. 600 dpi + color + pages(7-8, other SVG content) = 4''.

So there seems to be a weird, exponential jump from using 150 dpi to
300 dpi and above (tests 3 and 4). Color doesn't the variable here, as
hinted by tests 1 and 2. Tests 5, 7 and 8 show that the bottleneck
seems to reside in printing the world maps, so I've downloaded
"map.svg" and made a few more experiments:
 a. 600 dpi + color = 56'';
 b. same as before + remove 'canada needs fixing', circle with invalid
attribute ('param') and script = 54'';
 c. same as before + comment path with id "Russia" = 1'01'';
 d. same as before + comment path with id "Greenland" = 1'04'';
 e. same as before + remove 'stroke-linecap="round"' and 'stroke-
linejoin="round"' attributes = 56'';
 f. same as before + remove 'fill="url(#mapGradient)"' attribute =
2''.

The above tests show that the bottleneck seems to be that radial
gradient, probably being applied to such as high number of objects.
I've also tested with changing it to:

 <radialGradient id="mapGradient" cx="50%" cy="50%" r="50%"
gradientUnits="objectBoundingBox">
  <stop offset="0" stop-color="cornflowerblue"/>
  <stop offset="1" stop-color="blue"/>
 </radialGradient>

But the results were more or less the same (51''). I'm not sure if
this can be considered an implementation bottleneck or just a
potential content issue, as I'm convinced that the same effect
("global" gradient applied to land portions of the map) could be
achieved through a (conceptually better way such as a) "clip-path" or
maybe a "filter". What do you think?

All times were measured from when the "OK" button was pressed till the
display of the save PDF dialog. PDF printer used was PDFCreator 0.9.8.


I'm CC'ing Doug Schepers as he might be interested in seeing where
this thread ends up. Hope you don't see it as bug spam, Doug! ;-)


Hope this helps,
 Helder


[1] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre)
Gecko/20090625 Minefield/3.6a1pre (.NET CLR 3.5.30729)