dotnet / standard

This repo is building the .NET Standard
3.07k stars 428 forks source link

System.Drawing.Printing.PrinterSettings slow #1778

Closed vsfeedback closed 4 years ago

vsfeedback commented 4 years ago

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...

tarekgh commented 4 years ago

sorry, I'll move this to runtime repo instead. moved to https://github.com/dotnet/winforms/issues/8839