DrawToDevice performance

A forum for questions or concerns related to the PDF-XChange Core API SDK

Moderators: TrackerSupp-Daniel, Tracker Support, Vasyl-Tracker Dev Team, Chris - Tracker Supp, Sean - Tracker, Tracker Supp-Stefan

Forum rules
DO NOT post your license/serial key, or your activation code - these forums, and all posts within, are public and we will be forced to immediately deactivate your license.

When experiencing some errors, use the IAUX_Inst::FormatHRESULT method to see their description and include it in your post along with the error code.
Post Reply
pschlan
User
Posts: 10
Joined: Thu Nov 15, 2018 10:14 pm

DrawToDevice performance

Post by pschlan »

Hi,

I'm experimenting with the Core API SDK to print PDFs. I have to keep a very fast printer busy, so performance is critical. I've noticed that the application often is stuck in DrawToDevice() while CPU usage / IO on the machine is low and my application itself uses like 0 % CPU, and I don't know where the bottleneck is.

In another experiment, I'm printing different files in parallel from multiple threads, and it seems like performance is not improving. Is there some global lock on the Core API side? I'm currently testing with very simple files, and some calls to DrawToDevice() are fast, while others (drawing the same page from the same file) seem to be slow.

Any idea how to speed up things?

Best,

Patrick
User avatar
Tracker Supp-Stefan
Site Admin
Posts: 17824
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: DrawToDevice performance

Post by Tracker Supp-Stefan »

Hello Patrick,

I've passed your enquiry to my colleagues from the dev team, and asked them to comment here!

Kind regards,
Stefan
pschlan
User
Posts: 10
Joined: Thu Nov 15, 2018 10:14 pm

Re: DrawToDevice performance

Post by pschlan »

Thanks Stefan!

One update: I ran an experiment where I'm using multiple processes (instead of multiple threads), and this performs much faster. So it does seem to be an issue when calling this multiple times / in parallel in the same process. FYI, I do use a document instance per thread.
pschlan
User
Posts: 10
Joined: Thu Nov 15, 2018 10:14 pm

Re: DrawToDevice performance

Post by pschlan »

Tracker Supp-Stefan wrote: Thu Feb 09, 2023 11:58 am Hello Patrick,

I've passed your enquiry to my colleagues from the dev team, and asked them to comment here!

Kind regards,
Stefan
Any news here?
User avatar
Tracker Supp-Stefan
Site Admin
Posts: 17824
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: DrawToDevice performance

Post by Tracker Supp-Stefan »

Hello pschlan,

Apologies for the delay here!
Your case has been passed on to a colleague in the dev team, but it seems like I will need to 'nudge' them a bit!
I've started the internal process, and should have further news for you very soon!

Kind regards,
Stefan
User avatar
Lzcat - Tracker Supp
Site Admin
Posts: 677
Joined: Thu Jun 28, 2007 8:42 am

Re: DrawToDevice performance

Post by Lzcat - Tracker Supp »

pschlan wrote: Mon Feb 13, 2023 1:53 pm One update: I ran an experiment where I'm using multiple processes (instead of multiple threads), and this performs much faster. So it does seem to be an issue when calling this multiple times / in parallel in the same process. FYI, I do use a document instance per thread.
HI pschlan.
You are correct, issue is due to per process limitations in Windows API we are using. We have plans to migrate to a newer API in this function, but unfortunately there is no time frame for this and there is no warranty that this API will be much faster in multithreading scenario.
Glad you found at least one workaround and can purpose one more - you may set nFlags parameter to 0 (zero). This will render page to device as image (not as vector as in "problematic" method you are using). In this case multithreading should be working as expected, without need to run several processes. But this may change print quality and speed, so I cannot predict what will be better for your case.
Best, Victor.
Victor
Tracker Software
Project manager

Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.
Post Reply