4

I have a Win32 Direct2D application in which the user can draw primitives as well as load and manipulate pictures to create scenery. Afterward, the scenery can be printed or saved as a PDF file.

The process of printing D2D contents is explained by this article, which is also how I implemented it: https://learn.microsoft.com/en-us/windows/win32/direct2d/printing-and-command-lists

In summary, printing works by rendering the D2D contents to an ID2D1CommandList which is set to be the target for the ID2D1DeviceContext. After rendering the scene to the CommandList, I close it, add it as a page to an ID2D1PrintControl, close the ID2D1PrintControl (this sends all the commands to the printer) and restore my D2D resources afterward. PDF files are created by the same process, but I use the "Microsoft Print to PDF" as my printer.

All of these works. HOWEVER, when including large pictures, I noticed that the resulting PDF files were becoming pretty large. For example, I load a 4000 x 3000-pixel jpg into my app (which in and of itself has 5 MB file size), print to PDF --> the PDF would then have 28 MB and the print job would take several seconds to finish. On some machines, it even crashes (I think the ID2D1PrintControl::AddPage(...) function OR the ID2D1PrintControl::Close() function sometimes takes forever to return and the program does not respond).

Now, I know that D2D cannot use compressed images like jpg internally, that's why I create an ID2D1Bitmap from the jpg file first, which is also what I do use when printing.

Question: Is there any way to compress the images in D2D before they get to the printer? I assume that my problems come from large PrintStreams that cannot be handled properly by slow machines(?). I cannot scale the images as the resolution is important!

I realize that probably the PDF part could be fixed by using some PDF creation library and doing something like using the original compressed jpg and including that in the PDF, but I really want to avoid using some PDF library when usually the PDF printer works fine.

Any input to this topic would be appreciated since there is really a lack of information on D2D printing problems on the internet.

EDIT: I have now found a way to rasterize the pictures before sending them to the printer by setting DPI lower and drawing to a second commandList in order to make the resultant PDF files much smaller.

ONE last problem that remains is that on a few machines, the ID2D1PrintControl::AddPage(...) - function just does not return / it freezes the computer. No failure, no success, whenever one tries to print a complex scenery with multiple pictures. I have yet to look into: Printer Drivers, all the various printer settings I could try, directX version on those machines (probably has nothing to do with this). Does anybody have any other ideas about what could cause the AddPage-function to not return? Are there any typical installations that could be missing? Do the D2D1_TAGs that can optionally be entered as 4th and 5th parameters have any significance?

CptnAnalysis
  • 51
  • 3
  • Have you checked that: https://learn.microsoft.com/en-us/windows/win32/direct2d/improving-direct2d-performance#set-the-right-property-values-when-you-create-the-d2d-print-control you might want to try 96 DPI. Otherwise, do you have a reproducing sample? – Simon Mourier Jun 26 '20 at 12:09
  • Thank you for the hint about the article and the DPI settings. I have now found a way to rasterize my image by explicitly setting the DPI and working with a second command list that I draw the first to. Then, I print the second command list. The resultant files are much much smaller. So thanks for that. A problem that remains on some machines is that the ID2D1PrintControl::AddPage - function does not return. No error, no success, it just takes forever. Any ideas about what could make this function not return / has anybody encountered this bahaviour? – CptnAnalysis Jul 02 '20 at 12:25
  • 2
    You can enable the DX debug layer. Also break into the process with debug symbols enabled. Maybe you can see where it seems stuck, and have some hint about what's going on. And if you can reproduce, you should post that to Microsoft. You should also answer yourself on this question, and create another. – Simon Mourier Jul 02 '20 at 13:52

1 Answers1

1

I have now found a way to rasterize the pictures before sending them to the printer by decreasing the DPI of the PrintControl and using a second CommandList to which I draw the original one. I then proceed to use the second CommandList for the print job. Drawing the first CommandList to the second one forces earlier and more controllable rasterization before getting to the printer, which (depending on the settings) results in smaller PrintStreams.

Thanks to Simon Mourier for his help!

CptnAnalysis
  • 51
  • 3