rendering noticeably slower in the "Printing pages" phase

[sanfords]

wkhtmltopdf is doing a much much better job at handling page breaks than PhantomJS (Qt4.8.4)... There's no doubt about that. What I've found though is that wkhtmltopdf is running much more slowly than PhantomJS.

On a single test here PhantomJS is rendering a 2 ½ page PDF in less than 4 seconds, while wkhtmltopdf is up at almost 14 seconds.

I'm wondering if there's some sort of debug flag or something that may be slowing things down. Or maybe the page-break algorithm just more computationally expensive?

[ashkulz]

Can you share some information:

• test cases for which you did the timing
• OS/platform are you running it on
• version that you are testing, and if you compiled it yourself
• whether running it multiple times reduces the time taken to run

[sanfords]

Thank you for your time. Here are the details you asked for:

• phantomjs 1.9.7, stock
• wkhtmltopdf 0.12.1 built as described below
• input file at this gist: https://gist.github.com/sanfords/8929239#file-testreport-html
  (Sorry, I didn't know how else to include this here, data is fake.)
• Running the tests multiple times does not seem to make a difference.
• Mac OS X 10.9.1

Built with:

$git clone https://github.com/wkhtmltopdf/wkhtmltopdf.git
$cd wkhtmltopdf
$cd qt
$git checkout wk_4.8
$cd ..
$./build_osx.sh

phantomjs Results:

time phantomjs rasterize.js 'file:///var/folders/<snip>/input.html' test1.pdf Letter
real    0m2.716s
user    0m1.645s
sys 0m0.199s

wkhtmltopdf Results:

time wkhtmltopdf 'file:///var/folders/<snip>/input.html' test2.pdf
real    0m13.163s
user    0m11.568s
sys 0m0.736s

[ashkulz]

Hmm, I don't really have access to a Mac OS X system -- I'll try to see if I'm able to get the same results on Windows.

[ashkulz]

Ok, there is a noticeable pause in the "Printing pages" phase. That only happens for some pages, though -- I suspect that it is something to do with complex pages.

[sanfords]

I thought at first it had something to do with 'page-break-inside' support, since that's the one big difference for my own use. I just removed it and timing didn't change for wkhtmltopdf. Both wkhtmltopdf and phantomjs are using Qt for rendering? And both are using webkit? This is a strange one.

[ashkulz]

PhantomJS has pretty much the same patched QT/WebKit that is used by wkhtmltopdf. If you apply the table printing patch in patches/, you'll get almost the same functionality (WOFF fonts and CSS widows/orphans are not in it yet). As I said earlier, I'll investigate why it is taking so much time in that particular phase.

[sanfords]

Thanks for your efforts. I'm glad to see you got it reproduced. Hopefully some clever profiling and comparison will turn up some clues.

[sontek]

@ashkulz Any of progress on this? We are experiencing the same slow down.

[ashkulz]

@sontek: not really. I did find that it took the extra time in the webkit engine itself, but I didn't get time to figure out what the cause was.

[sontek]

@ashkulz Our major slowdown right now is with rounded corners. I need to generate a smaller test sample for you, but we disabled border-radius in our CSS and got a 30 second speed up

[ashkulz]

@sontek: How much time does it take now -- also, is the timing now comparable to PhantomJS?

[sanfords]

@sontek: Great call! I commented out /*border-radius: 5px;*/ and my rendering dropped from ~18 seconds to ~3 seconds. PhantomJS is freezing at the moment so I can't time that part there. The performance difference is consistent with what we saw three months ago, though.

[ashkulz]

I don't know why border-radius should cause extra rendering time in case of wkhtmltopdf although I suspect it should be something to do with the way the headless support is implemented. I'll document this workaround for the 0.12.1 release; we are planning to upgrade to Qt 5 in the near future so that may no longer be relevant then (as the headless support from PhantomJS will be reused).

[sontek]

@ashkulz When will the Qt5 upgrade be done? We had to go back to phantomjs because of another slow issue (outside of the rounded corners). I would love to test to see if the Qt5 upgrade fixes our problems.

[ashkulz]

There is no time-frame for when it will happen (i.e. it will get done when it gets done), but I can assure you that it won't happen for a few months at least.

[Jesus1302]

There is not only a problem with border-radius. I have also a slowdown with gradients.
If I set the following line instead of the radius, it takes about 10 seconds :
background: -webkit-linear-gradient(top, #C2C2C2 0, #D1D1D1 20%, #C2C2C2 50%, #B8B8B8 80%, #C2C2C2 100%) no-repeat;

And only one second with this 2 lines (and the pdf file generated is smaller and faster to load with acrobat):
background-repeat: no-repeat;
background: -webkit-linear-gradient(top, #C2C2C2 0, #D1D1D1 20%, #C2C2C2 50%, #B8B8B8 80%, #C2C2C2 100%);

The following lines are slow again :
-webkit-background-origin: border !important;
background-repeat: no-repeat;
background: -webkit-linear-gradient(top, #C2C2C2 0, #D1D1D1 20%, #C2C2C2 50%, #B8B8B8 80%, #C2C2C2 100%);

It is quite hard to understand why it is slow or not.
Unfortunately, I need rounded corners and gradients in my pdf, seems I'm not lucky.

[ashkulz]

There was a link to a blog post regarding this in the mailing list -- it is an issue in the browser engine itself. You may want to try and see if it is better with 0.13 alpha.

[Jesus1302]

Thanks, the version 0.13 alpha is really faster. But unfortunalely there is some problems with colors (color inversion) and the --zoom option doesn't work :
wkhtmltopdf.exe www.google.com --zoom 5 test.pdf

[navbhu]

I faced the same problem, but the performance increased not only when removing the border-radius but also by removing the background-color or border-style while keeping the border-radius.

The size of the PDF with all the style is very much higher (almost 10 times) when compared to the PDF generated after removing any one of the above styles.

I have also found there were images in the PDF when all these properties where there, and no images if any of those properties were removed. The images contain the background color of the two divs separately. The number of such images increases with the number of pages in the PDF. I used pdfimages command.

<html>
    <body>
        <div style="margin: 0px auto; width:1005px; border:1px solid  black; border-radius:6px; background-color:blue">
            <div style=" background-color:green; border:1px solid  red;border-radius:6px;margin-top:13px; position:relative;">
                1<br>2<br>3<br>4<br>5<br>6<br>7<br>8<br>9<br>10<br>
                11<br>12<br>13<br>14<br>15<br>16<br>17<br>18<br>19<br>20<br>
                21<br>22<br>23<br>24<br>25<br>26<br>27<br>28<br>29<br>30<br>
            </div>
        </div>
    </body>
</html>

I tried in Ubuntu14.10 with wkhtmltopdf version 12.2.1

[san983]

Found this same behaviour with the following css, as well in Fedora & OSX with 0.12.1 & 0.12.2.1. Also it spiked the CPU to 100%.

.br10fix        { position:relative; background-color:black; }
.br10fix:before { content:''; position:absolute; z-index:10; display:block; width:100%; height:100%;
                  background-color:white; border-radius:10px; }
.br10fix *      { position:relative; z-index:20; }

just removing these styles make the process went through fast & smooth 👍

[navbhu]

@san983 check with --dpi option with value as 72.

[brendon]

@san983, I think the culprit is most likely to be border-radius. I had a document taking about 60 seconds to render and removing border-radius brought it down to a couple of seconds!

I'd be interested to hear how you get on with the --dpi option too :)

[san983]

Thanks @navbhu & @brendon!
Actually with the --dpi option it works faster with the original css file 👍

But I decided to keep those styles off since they are not actually needed for my purpose.

[navbhu]

@brendon : In wkhtmltopdf QPrinter is initialized with HighResolution (dpi=1200), when dpi argument is used the value is replaced soon after initializing the QPrinter. I checked in PhantomJS where the dpi is set to 72 by default.

@ashkulz : correct me if I'm wrong.

[rthakur]

@navbhu Yes, you are correct slow down issues due high resolution dpi, if we use dpi=80 or less then it works perfectly. @ashkulz can you update default dpi, it is really hard to find devs why wkhtmltopdf getting too slow.

[brendon]

You're right in that it was the DPI setting causing problems for me too. 72dpi did the trick in the end. I'm going to see if wicked_pdf can set that as a reasonable default.

[thomasbalsloev]

Just a note that might help others.

After this commit our PDF creation ceased to function resulting in empty PDFs (no exceptions) on some systems (a test machine using Ubuntu and a developer machine with Linux mint, but worked on another developers Linux Mint). We are using wkhtmltopdf 0.12.1.

I finally traced this back to the dpi defaulting to 72. Raising it to say 100 made it work.
I haven't tracked this issue deeper to find out what the underlying reason is, but still this might be helpful if you're experiencing breakage after getting wicked_pdf version 1.0.2.

Best regard,
Thomas.

[brendon]

Hi Thomas. Thanks for letting everyone know. wicked_pdf has released a new gem version that reverts that change.

If you have the time and inclination it'd be really good to know what the differences in the environments were. Were you using prebuilt packages in each?

[thomasbalsloev]

Hi Brendon.

I've done some more digging and it seems this issue is related to this ticket (don't mind the windows stuff, the issue also found on linux): #1863

I haven't found a way to test/print the qt_defaultdpi value, but setting dpi in wicked_pdf to 75 (supposed to be default on Ubuntu/Mint) made it work with wkhtmltopdf 0.12.1 and wicked_pdf 1.0.2.

Setting dpi below (74 or the 72 default in wicked_pdf 1.0.2) re-introduced the breakage.
Migrating to wkhtmltopdf 0.12.2.x also fixed the issue. Also when using wicked_pdf 1.0.2.

This seems to confirm that my qt default dpi is 75 and the issue seen by me is the same as reported in the github link.

Cheers,
Thomas.

[brendon]

Thanks Thomas, that's quite interesting. I'll let David know and see what he wants to do with a default in light of this :)

[tbrianjones]

CSS Radius was causing 95% of my render time.

I have a relatively simple html page (400 lines of code, half css, a few tables, and one small logo image). It was taking 6+ seconds per page to render the pdf (which resulted in two pdf pages because of a purposeful break i added). I tried a bunch of things and nothing made a difference until i removed a couple radii in my css. Processing dropped from six seconds to <0.5sec.

examples:
border-radius: 8px;
border-top-left-radius: 6px;

[brendon]

@tbrianjones, take a look at what resolution your documents are rendering at too. This makes a difference along with the radius. I guess there's a bug in the routine that draws the curves, and at high resolution it takes ages.

[frenkel]

I'm not sure whether my colleageus have this exact same issue, but we have a number of Macs that take more than ten seconds to render even the simples HTML files. One other Mac with the same hardware and software renders it in less than one second.

Using dtrace we've discoved that the slow Macs do ten times as much calls to geteuid, ranging from 9600 to 11300, while the fast Mac does it with only 500 such calls. Does this info help to find the cause?

You can test it yourself using: sudo dtruss wkhtmltopdf in.html out.pdf 2> out.txt && grep geteuid out.txt | wc -l

[frenkel]

We've solved it already by removing all custom fonts. Rendering speeds went from 10 seconds to 1 second. Hope this helps somebody.

[jtomaszewski]

@frenkel what version of wkhtmltopdf do u have on your Mac?

[frenkel]

They use 0.12.3, because 0.12.4 has a regression.

[mitchdowd]

Watermark text with a 0.5 opacity across each page took my processing time from 0.7 seconds to 47.5 seconds, and the size of the document from 180kb to 2.2MB.