I need help - I can help - Implementing a new renderer

Implementing a new renderer

Printed From: Debenu Quick PDF Library - PDF SDK Community Forum
Category: For Users of the Library
Forum Name: I need help - I can help
Forum Description: Problems and solutions while programming with the Debenu Quick PDF Library and Debenu PDF Viewer SDK
URL: http://www.quickpdf.org/forum/forum_posts.asp?TID=2109
Printed Date: 20 May 24 at 3:39PM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com

Topic: Implementing a new renderer

Posted By: geoionescu
Subject: Implementing a new renderer
Date Posted: 23 Jan 12 at 9:03PM

Hello there QuickPDF developers and users,

I'm looking for a library to render PDF to screen and I came across yours.

I'm pretty much pleased so far with it's capabilities. Congrats!

What I'm looking after is rendering speed which is quite slow for some PDF's I'm dealing with compared with other libraries (like mupdf, for example) and wondering if anything can be done in order to improve it.

I'm thinking about implementing an http://www.antigrain.com/ - agg -based renderer. I've worked with it in the past and I was very impressed by it's speed and rendering accuracy. BTW, it's also http://cdn04.foxitsoftware.com/pub/foxit/manual/enu/FoxitPDF_SDK20_Guide.pdf - used by competition *caugh*foxit*caugh*

It could also be done internally (as you did with cairo), but also externally, provided you create rendering callbacks (e.g. like cbBeginPath, cbMoveTo, cbLineTo, cbSelectFont, cbDrawText etc), but I'm not sure about the speed implications with so many callbacks calls. You should know better.

Waiting for opinions,

Regards,

George

Replies:

Posted By: edvoigt
Date Posted: 26 Jan 12 at 3:16PM

Hi George,

I see the same problem. QuickPDF allows a lot of nice things in construction or manipulation of PDFs, but the rendering is very very slow. I look too for a solution like building a PDF by QuickPDF, puting it in a tempfile and rendering with muPDF or anything else. But I'm not so familar with C. So I wait and hope.

Cheers

Werner

Posted By: geoionescu
Date Posted: 26 Jan 12 at 6:12PM

Hello there Werner,

well, mupdf is really a fast renderer, but since it's GPL licensed, there's no way someone would use it in a commercial/close source app as, I think, many of QuickPDF users are doing.

As far as rendering with another backend, I don't think it should be a very hard task for QuickPDF developers! I was expecting a reply from them, though. Are there any channels I should use for direct contact, since I understand this is a user-to-user forum only.

Regards,

George

Posted By: edvoigt
Date Posted: 26 Jan 12 at 6:41PM

Hello George,

I did it many times since last summer, over the feature-issue-channel, because I found between version 7.23 and 7.24 a slowdown of 15-20 under identical conditions. The last info was, that after 8.13 may anything happen, but in 8.14 I see no effect.

The commercial problem exists for me too. But it is possible to by a lizence for muPDF, but I know nothing about pricing.

Cheers,
Werner

Posted By: geoionescu
Date Posted: 26 Jan 12 at 7:30PM

Hello Werner,

it is possible to http://www.artifex.com/indexlicense.htm - purchase commercial licenses from Artifex, but according to http://stackoverflow.com/questions/6714122/include-mupdf-in-android-project-eclipse - this post on SO, it's way too expensive for us, mortals (e.g. 42.000$ for the first year).

What I'd like to insist upon is the chance that the new agg-based renderer could lead to substantial rendering speed improvement.

OTOH, what's the feature-issue-channel you've mentioned?

Regards,

George

Posted By: edvoigt
Date Posted: 26 Jan 12 at 8:54PM

Hello George,

clear, this price is out of bounds. So muPDF is out of my eye. From agg I did hear first from your post.

This is the way to get in contact with Rowan or Andrew:
http://www.quickpdflibrary.com/support/feature-request.php - http://www.quickpdflibrary.com/support/feature-request.php

Cheers,
Werner

Posted By: geoionescu
Date Posted: 26 Jan 12 at 9:05PM

Hello Werner,

agg is used in haiku os as a windowing system, as a flash player in GNU's Gnash, in Rebol and matplotlib (see http://en.wikipedia.org/wiki/Anti-Grain_Geometry - http://en.wikipedia.org/wiki/Anti-Grain_Geometry ). It's also used by foxit and pdftron as pdf rendering backends.

To realize it's potential, you can start by browsing demos at http://www.antigrain.com/demo/index.html - http://www.antigrain.com/demo/index.html .

Thanks for the direct contact link. I've already contacted Rowan by mail and I'm waiting for an answer.

George.

Posted By: Rowan
Date Posted: 27 Jan 12 at 4:13PM

Hi George and Werner,

Anti-Grain Geometry is something we've previously looked at but were put off by the change of license in version 2.5. I see that Foxit are using version 2.3 of the license which was BSD, rather than GPL which the new version is.

Quick PDF Library currently uses GDI+ to help with the rendering of PDF files. We're currently working on adding support for using Cairo to assist with the rendering instead of GDI+ and after that is done we may investigate using AGG as well. We want to give our customers a few different options to choose from. Each different rendering engine has it's high points and low points.

Performance improvements for Quick PDF Library is definitely something that is high on our priority list and in fact it's next on the list. We've already done some profiling to identify bottle-knecks and in 2012 you should start to see some nice improvements.

Generally speaking performance improvements will come from examining specific PDF files and seeing how Quick PDF Library handles them -- there are an infinite number of different compositions for PDF files -- so don't hesitate to send through any PDF files which you don't think our library is processing fast enough.

Thanks for the feedback guys, keep it coming!

Cheers,

- Rowan.

Posted By: geoionescu
Date Posted: 27 Jan 12 at 6:29PM

Hello Rowan,

thank you for your reply.

Well, to be honest, I (almost) didn't notice QuickPDF was slow in rendering until I compared it with other libraries (e.g. mupdf).

I'm also a sofware developer and I'm quite paranoid when it comes to speed :-)

I also know from experience that optimizations are to pe berformed exactly where the bottlenecks are and, from what I've noticed, including speed differences between GDI+ and Cairo, implementing antigrain as a renderer could lead to rendering speed improvements.

Well, I guess you could use version 2.4 which is http://www.antigrain.com/license/index.html#toc0002 - distributed under a modified BSD license . The differences between 2.5 and 2.4 are quite negligible.

Cairo rendering is slower than GDI+ and I see no reason to use it, except if you would provide something live SVG output, for example, which I know for sure Cairo supports it natively.

Great!

Well, my opinion is that you could start by comparing it with other libraries (like mupdf) in terms of rendering speed and try to achieve similar timings.

Although I do prefer to work low level, I guess you could start by using http://www.point.com.mk/aggplus/ - AggPlus , which is a library which emulates GDI+ API using Antigrain. You will also find there a demo which compares agg to GDI+ in terms of timing and rendering accuracy.

I must admit that font rendering in agg is something to be optimized, but I'm pretty sure you guys can do a great job (besides several tricks already mentioned on agg's mailing list) ;-)

Thanks,

George