System.Drawing.Printing.PrinterSettings slow

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

Hello

I'm debugging a problem with the printer settings. Some calls are significant slower if the default printer is a network printer, even if I explicit set a local printer name.

After studying referencesource I think I found the culprit.

I call:

var printerSettings = new System.Drawing.Printing.PrinterSettings();

printerSettings.PrinterName = "LOCALPRINTER";

// the next call is slow if the OS default printer is a network printer
var res = printerSettings.DefaultPageSettings.PrinterResolution

Internally FastDeviceCapabilities is called.

FastDeviceCapabilities calls GetOutputPort. But GetOutput port return the port of the default printer and not the port of the given printer!

In addition, DeviceCapabilities is then called with a wrong combination of printer name and port, don't know if this could lead to additional problems.

Resolution: GetOutputPort should return the port of the given printer and not accessing the default printer at all.

Best Regards,
Raphael

---

Original Comments

Raphael Affolter on 1/20/2020, 04:03 AM:

I forgot to mention: .Net Framework 4.6.1

Feedback Bot on 1/20/2020, 06:51 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Raphael Affolter on 2/7/2020, 08:39 AM:

Because we print a lot, we really suffer from this performance penalty.

Also reading PaperSizes and PaperSources from the printer settings is slow caused by the same problem.

Could you please inform me about a possible fix?

Best Regards,

Raphael

Raphael Affolter on 2/7/2020, 10:33 AM:

In my opinion the fix is easy: replace GetOutputPort by OutputPort in the call to

FastDeviceCapabilities.

Done.

Feedback Bot on 2/27/2020, 05:40 PM:

I have detected that for the last 35 days, this issue didn't have much product team activity and a very small amount of new votes or comments. Based on this, its severity, and affected area, it’s my experience that this issue is very unlikely to be fixed.

Dada Huo [MSFT] on 10/20/2020, 01:57 AM:

Thank you for taking the time to log this issue! Did you still reproduce this issue in the latest stable version of Visual Studio installed from https://visualstudio.microsoft.com/downloads ?

If so, in order for us to investigate further, please provide more information by recording your repro steps via the Visual Studio Feedback Tool (Help -> Send Feedback -> Report A Problem). The feedback tool will ensure that we collect the needed information for you without worrying about what to provide (recording, dump file or ETL trace). Since this issue is now marked as Need More Info, that workflow is enabled in the Feedback Tool– full instructions
In our guidelines , you can get tips on how to provide clear and simple reproducible steps.

Get performance issues fixed quicker, please see https://docs.microsoft.com/en-us/visualstudio/ide/how-to-increase-chances-of-performance-issue-being-fixed?view=vs-2019.

We look forward to hearing from you!

Raphael Affolter on 10/20/2020, 02:28 AM:

Thanks for answering.

The issue is not about Visual Studio, the problem is in the .Net Framework (at least 4.6.1).

By studying the source code on referencesource.microsoft.com I spotted calls to the default printer, even if I print on another printer. If the default printer is a network printer, this slows down the printing process significantly.

Please have a look if you can fix this in the .Net Framework(s).

PrinterResolution, PaperSizes and PaperSources of System.Drawing.Printing.PrinterSettings are affected.

I also mentioned a fix: replace GetOutputPort by OutputPort in the call to FastDeviceCapabilities...done.

I you need a repro project, I can provide one.

---

Original Solutions

Raphael Affolter solved on 3/19/2020, 07:18 AM, 0 votes:

I would be helpful if at least somebody reacts on this issue. I even told you how to fix the problem...

[ghost]

Tagging subscribers to this area: @safern, @tannergooding, @jeffhandley
See info in area-owners.md if you want to be subscribed.

[lockiegarnett]

Exact same issue!

[lockiegarnett]

Developing in vb.net
Using dot net 4.8 framework.

We generate a preview after accessing the printer settings (not printing at this point)
System.Drawing.Printing.PrinterSettings

• PrinterResolution
• PaperSizes
• PaperSources

Additionally Network Printing Settings Load Times are affected by:

• Remote servers internet latency (multiple repeat trips to get a single printers settings?)
  e.g.
  37ms = 7 seconds to load printer settings.
  122ms = 15 seconds to load printer settings.

• Remote server disk speed (surprisingly)
  e.g.
  Testing on AWS with disks providing 38,000 IOPS = 45 seconds to load printer settings.
  Testing on AWS with disks providing 43,333 IOPS = 20 seconds to load printer settings.

[pavelsokolovan]

Same issue - delay from 100 msec to 6 sec on read PrinterSettings.PaperSources property

[mdell-seradex]

I am also seeing this delay. Sometimes it is much longer than 6 seconds because the Network Printer is across the country.

[mdell-seradex]

Note that I traced what he was saying and I think I see it.
printerSettings.DefaultPageSettings.PrinterResolution (PrinterResolution) internally calls PrinterResolutionFromMode when not set up, which then calls Get_PrinterResolutions, which in turn calls FastDeviceCapabilities which uses GetOutputPort() which does indeed seem to read from the default printer accoring to the API PRINTDLGA structure's flag PD_RETURNDEFAULT.

[vruss]

Is this also slow in .NET 7+?

[elachlan]

I think we would remove GetOutputPort and use https://learn.microsoft.com/en-us/windows/win32/printdocs/getprinter, it would then return the specified printers information (with the portname) which we then can pass to DeviceCapabilities.

Other option is to use https://learn.microsoft.com/en-us/windows/win32/printdocs/enumprinters and loop the results to get the correct printer and its port.

[mdell-seradex]

@elachlan, I am for anything that would fix this bug. Hopefully it does not slow down this method during normal use. Also, hopefully the fix will be included in .NET Framework 4.