SVG printing performance
HelderMagalhaes
A few days ago, I tried printing the "SVG Parameters 1.0, Part 1:
Primer" [1] in Firefox stable [2] and it just appeared to freeze so I
killed it after a couple of minutes. Today, I got back at the subject
with a few more spare minutes and started by trying Firefox nightly
[3] (which, by chance, gave slightly better results). :-)
Given that document holds a couple of complex SVG files (World maps)
and that the "examples are emulated by a Javascript prototype" [1],
this seemed to be the proper place to start digging on this...
Steps to reproduce:
1. Go to "SVG Parameters 1.0, Part 1: Primer" [1];
2. Choose "File", "Print...";
3. Set up printer preferences (if any) and press OK.
Expected result:
The document would be printed within a reasonable time.
Actual result:
An apparent freeze occurs at 63%. While Firefox nightly takes a couple
of minutes to unleash and slowly proceed, Firefox stable takes more
than 10 minutes!...
Additional information:
Few environment details:
* Operating system is Windows XP SP3;
* Hardware consists of a Pentium IV 3.0GHz with 2GB of RAM;
* Graphics adapter is an ASUS A9250 (ATI Radeon based).
Call stack of the thread which takes the CPU:
ntoskrnl.exe+0x584d
ntoskrnl.exe!IoPageRead+0xae0
hal.dll+0x2ef2
xul.dll!NS_InvokeByIndex_P+0x42749
I'm not sure if I should start by reducing this issue first but, given
the amount of TODO items involving bug reduction in my stack, I felt
like it was a good idea to create a thread on this first and move it
to Bugzilla if this is seen as a bug and, at the same time, act as a
reminder for whenever I have the chance to get back at this. :-)
Regards,
Helder
[1] http://www.w3.org/TR/2009/WD-SVGParamPrimer-20090616/
[2] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/
2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
[3] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre)
Gecko/20090622 Minefield/3.6a1pre (.NET CLR 3.5.30729)
Daniel Holbert
to a PDF file in 7 seconds on Firefox 3.0.11, and in 6 seconds on a
trunk nightly.
However, if I instead print to a PS file (or a real printer), it takes
25 seconds on FF3 & 22 seconds on trunk, and it spends most of that time
hanging at around 60%. (like you described) The PS file is also about
5x as large as the PDFs were. (3.7 MB vs 750 KB)
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?
My Build IDs:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009060309
Ubuntu/9.10 (karmic) Firefox/3.0.11
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090625
Minefield/3.6a1pre
~Daniel
HelderMagalhaes
> 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)