PDF Files with large bitmaps slow to display

[johnr@etakeoff.com]

We're seeing PDF files containing large bitmaps display much more slowly with the PXCView SDK (0r the PDF XChange Viewer) than with Adobe. The problem is particularly bad with older CPUs.

The file below displays in about 1 second in Adobe but takes nearly 10 seconds with PXCView.

http://etakeoff.com/download/VerySlow062211.pdf

[John - Tracker Supp]

Hi John,

can you please describe a typical systems resources there or perhaps use the option Help-> report a problem to send a sample systems tech info for us to investigate.

My somewhat basic laptop here takes about 7-8 sec's in our Viewer and Adobe 4-5 secs - so for sure there is a definite issue - but not of the magnitude you describe - there are also improvements coming which will help here in upcoming versions - also changing the memory allocated from Automatic to 50% yielded signifcant improvements (edit menu preferences -> performance)

and one signifcant benefit of the way PDF-XChange perfroms once the file is loaded - scrolling backwards to the top of the file is immeadiate - whereas Adobe will reload/refresh the page causing a delay - so there are pluses and minuses - its not all one way traffic ....

[johnr@etakeoff.com]

I'll work on getting more information about the systems where we see this.

We're using the SDK. How can I use that to do the equivalent of "changing the memory allocated from Automatic to 50%"?

You say "scrolling backwards is immediate". Does that mean you're cacheing all viewed pages? In our application that sould be a problem. Is there a way to disable that or clear the cache?

[Tracker Supp-Stefan]

Hello John,

Please see the MemUsage object under
2.2.2.13 Performance in the Viewer AX SDK Manual for the possible values.

Yes we are caching the already rendered pages, but you can limit the maximum amount of memory our Viewer can use by the MemUsage in percentages.

After speaking with our developers further, there is even one more way to control the amount of memory that our Viewer could allocate -using the undocumented boolean UseMemExact object along with the simple integer property MemExact which contains the number of MB of RAM that our Viewer could allocate. If UseMemExact is false (which it is by default) the Viewer will use the value stored in MemUsage.

Best,
Stefan

[johnr@etakeoff.com]

We're using the simple SDK rather than the ActiveX. I don't see anything on MemUsage in the help.

We're already using PXCV_ReleasePageCachedData.

[Tracker Supp-Stefan]

Hello John,

I asked our project leader to check this and he says that we are slower in decoding JBIG2 images. He is now investigating why this is so and what we can do to improve the performance in this aspect.

Best,
Stefan
Tracker

[johnr@etakeoff.com]

I'm not sure that's the case we're seeing. I would expect you to decode them once when you load the page. We're seeing each screen refresh be slow as we pan and zoom.

[Lzcat - Tracker Supp]

pxcview.dll does not cache rendered page, but it cache internal PDF structure, decoded images, etc. PXCV_ReleasePageCachedData may releae them, so on each draw they will be decoded. Which parameters are you passing to PXCV_ReleasePageCachedData and how often do you call it?

[johnr@etakeoff.com]

When the user moves from one page to another, we call it on the previous page:

PXCV_ReleasePageCachedData(m_doc, nPgRelease, pxvrcd_ReleaseDocumentImages);

The slowness we're seeing happens even when zooming and scrolling on the same page.

[Lzcat - Tracker Supp]

That is strange. Can you post code which is used for drawing?

[johnr@etakeoff.com]

void CRViewImgPdf::Draw(CDC* pDC, const RECT* pRectDst, const RECT* pRectCrop, UINT nFlags) const
{
PXV_CommonRenderParameters dp;
HRESULT hResult;
double dblMult;
RECT rectPg;
RECT rectDraw = *pRectDst;

dblMult = ((double)(pRectDst->right - pRectDst->left))
/ ((double)(pRectCrop->right - pRectCrop->left));
rectPg.left = (int)(0.5 + dblMult * (double)(-pRectCrop->left));
rectPg.top = (int)(0.5 + dblMult * (double)(-pRectCrop->top));
rectPg.right = rectPg.left + (int)(0.5 + dblMult * (double)m_nWidth);
rectPg.bottom = rectPg.top + (int)(0.5 + dblMult * (double)m_nHeight);
dp.WholePageRect = &rectPg;
dp.DrawRect = &rectDraw;
switch (m_nRotation)
{
case 0 : dp.Flags = pxvrpf_Rotate_NoRotate; break;
case 90 : dp.Flags = pxvrpf_Rotate_Rotate90CW;break;
case 180 : dp.Flags = pxvrpf_Rotate_Rotate180; break;
case 270 : dp.Flags = pxvrpf_Rotate_Rotate90CCW;break;
default: ASSERT(FALSE); break;
}
dp.Flags |= pxvrpf_NoTransparentBkgnd;
dp.RenderTarget = pxvrm_Viewing;
pDC->FillSolidRect(pRectDst, RGB(255,255,255));
hResult = PXCV_DrawPageToDC(m_doc, m_nPageCurr, pDC->m_hDC, &dp);
}

Here's the page change code:
BOOL CRViewImgPdf::PageCurrSet(int nPage)
{
BOOL bResult = TRUE;

if (nPage != m_nPageCurr)
{
int nPgRelease = m_nPageCurr;

m_nPageCurr = nPage;
if (nPgRelease >= 0)
{
PXCV_ReleasePageCachedData(m_doc, nPgRelease,
pxvrcd_ReleaseDocumentImages);
}
}
return (bResult);
}

[Tracker Supp-Stefan]

Hello John,

Victor did check and confirmed that there is an issue with the caching for drawings not working correctly.

I have created a ticket so this can be investigated:
#1121: SDK Viewer 2.5.196: PDF Files with large bitmaps slow to display
But whether it will be fixed depends on whether there will be a new build of our ver2 SDKs, as we are now working on ver3, and as ver3 is completely different this bug is not present there, so no fixing will be needed.

In any case we will keep you updated with any news on the subject as they become available.

Best,
Stefan

[johnr@etakeoff.com]

Any estimate on when version 3 might be released?

[Tracker Supp-Stefan]

Hello John,

I am afraid that we can not be any more specific than this:
https://forum.pdf-xchange.com/ ... hp?t=10100

Best,
Stefan

[johnr@etakeoff.com]

Any update on when the next version will be available?

[Tracker Supp-Stefan]

Sorry John,

But still nothing more specific than what is posted in the topic I linked earlier.

Best,
Stefan

[johnr@etakeoff.com]

Is this fixed in 2.5.199?

We're getting majopr complaints from our end users on this problem.
http://forum.etakeoff.com/topic/time-delay

[Paul - Tracker Supp]

Hi John,

I checked the Support Request Ticket for this (RT#1121: SDK Viewer 2.5.196: PDF Files with large bitmaps slow to display) and it is reported as being fixed for the next build. That was before 198 so it should be good for 199. I've asked for confirmation of that. Have you tried it in 199?

regards

[johnr@etakeoff.com]

Just downloaded and installed it. It fixed the problem. Thanks.

Is there any place to subscribe to get notices when a new release is posted?

[Jamie - Tracker Supp]

Hi John,

Indeed there is! In the Communication Preferences section of your user account there is an option labeled, "New Product Availability Notifications". Simply place a check beside this.

Regards,
Jamie.