.NET 5 - Printing - XPS requires STA Threads

[wstaelens]

Issue Title

Printing in .NET 5 requires XPS but this requires STA Threads.
Why is this needed?

Is it possible to render or process XPS in separate threads instead of STA?

This is a serious limitation, XPS printing is slow as heck.

[wstaelens]

any updates on multithreading and printing XPS?

[scalablecory]

In Framework you were able to create your own STA threads and do multi-threaded XPS rendering. I don't know if this is still the case in .NET 5.

[SamBent]

Printing is STA because it uses resources that are STA (packages, print queue, etc). If you're printing visual content, you obviously need to be on the (STA) UI thread that allows access to the content.

.NET 5 supports multiple STA threads, exactly the same as .NET Fx. Use this to get "multi-threaded printing", in the sense of several independent print tasks each running on its own thread. If you're asking about several threads cooperating on a single print task, that's probably never going to happen - printing is inherently sequential.

[wstaelens]

accepting a print job from a V4 driver plugin really has some issues.

First of all, see "XPS documents in .NET Core can't be opened" ( #3546 )

Next one of the biggest issues is the performance of XPS.

Having for example a document of 3000 pages being printed to a V4 driver. Because of the very annoying STA requirement, it takes ages to render the pages sequentally. We can't render the pages in parallel (if possible in C#, feel free to explain how), in other words other code and logic that works on individual pages is unable to go parallel and is slow because it all has to go sequentially. Eventually we go out of memory as we can't hold all the rendered pages for some actions we are doing.

The performance issues can easily be reproduced with Microsoft's own XPS Viewer and Microsoft XPS Document Writer (printer). When opening the original pdf (3MB) and we print it to the Microsoft XPS Document Writer printer as an .xps, it takes ages to print. Once it has been printed we have an .xps file grown to 50MB. Opening the xps in Microsoft XPS Viewer and searching a word (which exists e.g. on page 2668) literally takes ages as it processes sequentally through the document. Sumatra finds the word in about 50 seconds, XPS Viewer does it in ±6 minutes. (to compare: foxit reader on the original pdf does it in 25 seconds).

I can't share this big file (confidential) but just take some pdf files, ebooks in pdf, with a lot of pages and print them. (or print and capture the XPS print jobs with a render filter to catch the xps on the microsoft generic V4 driver.)

Can these XPS printing issues please be tackled or prioritized?

.NET SDK 5.0.202
.NET runtime 5.0.5
Windows 10 20H2 (19042.928)
Windows Server 2019 1809 (17763.1879)

[miloush]

As it has been mentioned, you can create multiple STA threads, could you not use it to render pages or sections in parallel and then combine them into one document?

[wstaelens]

@miloush i don't see how this can be faster unless you have 1000+ pages and even then, opening it several times and combining it again will drop your performance gain...

[wstaelens]

@miloush also XPS is STA. An XPS Document can NEVER be attached to multiple threads. Processing and manipulation speed of large documents because of STA is really 🐌

[miloush]

@wstaelens your example had 3000 pages. It might help if rendering the elements is what takes the most time.

You asked for multithreading, we said you can have multiple STA threads. If printing itself is the bottleneck, then that's a different issue - and if you can reproduce it by printing PDF to a XPS printer I am not entirely sure this is within the scope of WPF.

What is the nature of the document? Is it UI elements, plain text, or a photo per page? A repro would be helpful only if it was random content.