General Discussion - RenderPageToDC performance question

Print Page | Close Window

RenderPageToDC performance question

Printed From: Debenu Quick PDF Library - PDF SDK Community Forum
Category: For Users of the Library
Forum Name: General Discussion
Forum Description: Discussion board for Debenu Quick PDF Library and Debenu PDF Viewer SDK
URL: http://www.quickpdf.org/forum/forum_posts.asp?TID=2794
Printed Date: 23 Nov 24 at 12:16AM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com

Topic: RenderPageToDC performance question

Posted By: EOlson
Subject: RenderPageToDC performance question
Date Posted: 05 Dec 13 at 5:33PM

I am using the QuickPDF libary version 8.16 and have a question about how the RenderPageToDC works in the context of my application.

My application is written in Delphi and implements a banded report print engine. To render a page of PDF to a printer, my application passes the handle to the canvas of the active printer driver to RenderPageToDC along with the resolution and page number.

The problem I am having is that for even relatively simple pages (few objects to print), the size of the spool file that is generated is surprisingly large and the rendering is slower than if I was using the GDI to render the objects that are on the page. Is RenderPageToDC creating a raster image or EMF image of the page before using GDI+ to get the output to the device context? If so, is there a way to skip the interim step?

any help would be greatly appreciated!

Erik Olson

Replies:

Posted By: EOlson
Date Posted: 05 Dec 13 at 9:26PM

BTW, I'm using Delphi 6

Posted By: AndrewC
Date Posted: 06 Dec 13 at 5:07AM

Erik,

We will be doing some work in this area in the coming months to reduce the spool file size. There are always areas in the library to optimise and we don't have the milllion dollar budgets like Acrobat nor the expensive licensing fees either that they charge.

Andrew.

Posted By: EOlson
Date Posted: 06 Dec 13 at 3:10PM

Andrew, can you tell me in general terms, is the file size problem due to the page being rasterized before being rendered to the device context or is the function truly rendering individual objects to the device context directly? I have a project that is being held up on the performance of this function and am trying to determine a couple of things here:

1) If you're not already rendering directly to the device context (i.e., there is some interim step of converting to an image before rendering to the device context), is it feasible to cut that step out?

2) If there is such an optimization available, would you be open to working that change in an expedited fashion given that we fund that effort, or possible allow us to make that change to your source for us to use (and you to have for your other clients)? We would be willing to discuss any of these type of options with you if you would be agreeable.

Also, have there been any significant improvements in that function since version 8.16 that would make it worth my while to upgrade?