Slow performance for certain PDFs containing images

[martin2]

Hi,

we use the viewer to display PDFs which embed scanned images. Now we recognized that there are some images which are displayed extremely slow (1-page PDF about 5-10s for display). We already tried to switch of image and text anti-aliasing and used Microsoft ICM as suggested in a former post - but performance did not improve significantly.

The embedded images are scanned in 300dpi and 24bit color resolution. I attached a sample for such an image.

Are there any recommendations how we should embed images in our PDF in order to get better displaying performance?

Thanks
Martin

[Tracker Supp-Stefan]

Hi Martin,

Can you please specify which build of the SDKs are you using, as the file while containing a big image loaded for about a second on my machine - using the stand alone Viewer (build 2.0.46).

Best,
Stefan

[martin2]

Hi Stefan,

we use Version 2.0 - Build 44.0

If I open the file with the standalone viewer it needs several seconds and you can see how the image is displayed top-down. Overall it needs from about 5s (fast client machine) to over 10s (on an older machines). But it really depends on the contents of the image. I also have another file (unfortunately I am not allowed to send it). This file has 8 pages, about 15MBytes of size, containing complex images but it displays nearly immediately also on the older machine (max 1s for the first page and for scrolling through the file). Therefore we think it is something specific in this file and with the image but we have no clue where to search for.


Martin

[Lzcat - Tracker Supp]

Your file contains a large Raster image (about 24.8 Mbytes), and we place the decoded image into a temporary file. Different windows versions have different strategies when actually writing a temporary file to the hard drive, so we can get very different results.

If the target PC has not so much RAM and a slow hard drive initial decoding may seriously degrade performance because of flushing of the decoded data to the hard drive. We will see what can be done with this.

PS. Your file contains a broken object (characters marked using red color should be removed):
28 0 obj
<<
/Type /OutputIntent
/S
/GTS_PDFA1
/OutputConditionIdentifier(AdobeRGB1998)
/DestOutputProfile 29 0 R >>
>>
endobj

[martin2]

Hi Victor,

I checked my temp-directory an can see a pxv...tmp-file of about 24MBytes. Is this the uncompressed image? I compared this with the other PDF I mentioned with 8 pages and about 15MBytes size. It contains other scanned images (same resolution, same color depth). But for this image I get temp-files of between 3 and 6 MBytes. And this PDF opens much faster. Maybe this information helps.

Martin

[Lzcat - Tracker Supp]

Hi Martin.
Yes, this is images (and may be other temporary data such as fonts, but fonts are often much smaller).

More helpful information will be the PC configuration where a file renders slowly: OS version, CPU, RAM (size and maybe speed), HDD model. However regardless of this information all we can offer in the current realization - do not cache such images. So firstly drawing become's faster (no storage of data to hard drive), but if you change the zoom (for example) - the image will be drawn more slowly (compared to when cahching is active - because it will be decoded each time when needed).

Is this acceptable? (of course you will be able to turn on/off caching of large images).

HTH

[martin2]

Hi,

I have tried on two machines:
- slow machine: Desktop Pentium 4, 3 GHz, 2GByte RAM, 80GByte HDD
- fast machine: Notebook, Core 2 DUO T9400, 2.5 GHz, 3 GByte RAM, 250GByte HDD

I made more tests yesterday evening. I do no longer think it is the temp-file. I constructed an image in PNG format which compressed had only 32kByte but uncompressed has still 24MByte. It opens immediately although it has to write the temp-file. It looks as if images that originate from a JPG are slower then images originating from compressed PNGs (I also did this for a PDF with an image similar to that I sent already sent to you - it has about 8MBytes (compared to 1.5MByte for the JPG-based doc), decompresses to 24MByte temp-file, but opens much faster then the other).

By the way - I also experimented whether the virus scanner may have impact but could not recognize any difference.

Martin

[Lzcat - Tracker Supp]

Can you provide a file which open faster to us? Will see where is difference.

[martin2]

Hi Victor,

I am not able to upload the file, as the PNG based image has a size of nearly 10MByte. Is there another way to upload a larger file?

Martin

[Lzcat - Tracker Supp]

Please send it to me - lazycat@tracker-software.com

[martin2]

Hi,

I sent two versions of the PDF: one created out of a JPG, one created out of a PNG.

Martin

[John - Tracker Supp]

Thanks - Victor will reply in due course.

thanks for your patience.

[martin2]

Any news regarding this topic?

Martin

[Tracker Supp-Stefan]

Hi Martin,

Just spoke with Viktor - it turns out to be a more complex issue that initially thought.
We are now discussing this in the team and will let you know the result of the discussion.

Best,
Stefan

[martin2]

Stefan,

are there any news about this issue. We still have the problem and as more and more documents are scanned in our productive system the severity of this issue rises from day to day.

Martin

[Tracker Supp-Stefan]

Hi Martin,

I am afraid that there is no update on this matter yet.
Image manipulation would be changed in the new version we are preparing (v3).

Regards,
Stefan

[cool_sphere]

Hi Martin,

I am afraid that there is no update on this matter yet.
Image manipulation would be changed in the new version we are preparing (v3).

Regards,
Stefan

Is there any plan to solve this problem?
When I view some pdf files which contain images, many .tmp files are created automatically and fully fill my hard disk. It's boring. I have to use other pdf viewer software now, such as "foxit pdf viewer".

[Tracker Supp-Stefan]

Hello cool_sphere,

You have posted in an SDK topic - are you using our developer products?

The end user Viewer shouldn't be creating any excessive number of .tmp files while just opening a document. Please check your Edit -> Preferences -> Performance options, and make sure you haven't allowed e.g. 100% of your memory to be used for image rendering - as in this case - windows might need to start swapping some other applications if you are browsing an extremely heavy file on a low memory machine.

Best,
Stefan

[cool_sphere]

Hello cool_sphere,

You have posted in an SDK topic - are you using our developer products?

The end user Viewer shouldn't be creating any excessive number of .tmp files while just opening a document. Please check your Edit -> Preferences -> Performance options, and make sure you haven't allowed e.g. 100% of your memory to be used for image rendering - as in this case - windows might need to start swapping some other applications if you are browsing an extremely heavy file on a low memory machine.

Best,
Stefan

Hello Stefan,
I'm using end user Viewer, not developer products. I choose all the default options.
When I view a file, if a page is an image, a big file named pxv**.tmp will be created in the Windows temporary directory. If I view many different pages, many pxv**.tmp files will be created and my harddisk will be low diskspace.
A two-page pdf file is as attached as an example.

Best,
cool_sphere

[Tracker Supp-Stefan]

Hello cool_sphere,

Thanks for the follow up and sample.

After testing with your sample file - here are the results we got:
Opening the file on my machine generates 2 files - each about 6.3 MB - I presume one for each page.

My colleague Paul got a few smaller files - with a total size of 3.14 MB.

May we ask what size are the tmp files at your end for the same sample file?

These temp files are necessary for the proper operation of our Viewer, and can not be turned off, but even with 10 such image based files - with 20 pages in each - in a worst case scenario will take less than 1GB of storage space. Yes this can be a lot on a laptop with e.g. 40-60 GB hdd - but there isn't much we can do in this case other than recommend you to use just a few files at a time, or try to free up some storage space.

Best,
Stefan
Tracker

[cool_sphere]

Hello cool_sphere,

Thanks for the follow up and sample.

After testing with your sample file - here are the results we got:
Opening the file on my machine generates 2 files - each about 6.3 MB - I presume one for each page.

My colleague Paul got a few smaller files - with a total size of 3.14 MB.

May we ask what size are the tmp files at your end for the same sample file?

These temp files are necessary for the proper operation of our Viewer, and can not be turned off, but even with 10 such image based files - with 20 pages in each - in a worst case scenario will take less than 1GB of storage space. Yes this can be a lot on a laptop with e.g. 40-60 GB hdd - but there isn't much we can do in this case other than recommend you to use just a few files at a time, or try to free up some storage space.

Best,
Stefan
Tracker

Hello Stefan,

The sample I provided is just an example that demonstrates the situation. I have many files with about 300 pages in each, then the problem is much more serious. But these files are classified and I can't provide them as samples.
Though the hdd storage space may be large, I don't think it is an efficient way to create so many tmp files and take large space on a hdd. Other viewers don't perform like that, such as Adobe acrobat pro and Foxit pdf reader. I hope it can be improved in version 3, then users will love our viewer much more.

Best,
cool_sphere

[Tracker Supp-Stefan]

Hi cool_sphere,

And thanks for the follow up. I can see your point and we are now discussing this in the team to see if we can provide a way to limit/turn this off in the current version, and yes - ver3 will certainly bring many changes!

Best,
Stefan

[Tracker Supp-Stefan]

Hello cool_sphere,

After further discussing this - I am afraid that nothing can me done in the current version, but we will certainly work in this respect in ver3. We do now have a firm release date for ver3 - so it's not that far away.

Best,
Stefan