[MBS] Dyan PDF Question (MBS Xojo Plugin Mailinglist archive)
|Re: [MBS] IconImageMBS slow 10.9 - Garth Hjelte|
|[MBS] Dyan PDF Question - Peter Truskier|
|Re: [MBS] Dyan PDF Question - Christian Schmitz|
|[MBS] Dyan PDF Question|
|Date: 06.01.15 01:43 (Mon, 5 Jan 2015 16:43:49 -0800)|
|From: Peter Truskier|
We are using DynaPDF Pro to, among other things, create a PDF Viewer in one of our projects. We are trying to implement a function that requires zooming in to create a small raster image (on the order of 200 X 200 pixels) from a very small section of the PDF. The zoom factor can be as high as 250X, so the size of the PDF rect being rasterized is on the order of 1 pt X 1 pt.
We do this by setting the cropBox to whatever we need, and then rasterizing the portion of the PDF within that cropBox. The performance of doing this is surprisingly good - on the order of a one or two hundred milliseconds - IF the crop area is near the upper left hand corner of the PDF.
But, the performance really begins to suffer as a function of the distance of the crop area from the upper left. For example, if it is near the lower right corner of a letter- or a-4 size PDF page, the rasterization time can be several seconds, and in some cases, the result is an empty picture even though the DynaPDFRasterizerMBS.renderPage function does not return “false.”
Is this performance dependence just a feature of the implementation which one can’t get around, or are there solutions to improve the performance?
|Re: [MBS] Dyan PDF Question|
|Date: 06.01.15 19:27 (Tue, 6 Jan 2015 19:27:43 +0100)|
|From: Christian Schmitz|
> Is this performance dependence just a feature of the implementation which one can’t get around, or are there solutions to improve the performance?
I forwarded question to Jens and got this answer:
First, you must restrict the zoom factor to avoid a number overflow. If the monitor resolution is 96 DPI then the zoom factor must be restricted to 64. The real zoom factor is then 64 + 96 / 72 = 85.33.
The zoom factor must be further restricted if the monitor resolution is higher since the rasterizer uses 24/8 bits fixed integer coordinates.
The current implementation is generally not designed to render tiles. A tile renderer depends on a cached content stream and it requires another clipping technique to avoid gaps between tiles.
RenderPage() must decompress and parse the entire content stream over and over again for every tile. This is inefficient and wastes a lot of processing time.
However, a tile renderer will be available soon (probably within the next six weeks).
Maybe you wait just a few weeks until the new tile renderer is available.