Hi PDFBox users and maintainers, Thank you again Tilman for your swift response.
As requested, I've lodged a PDFBox jira ticket here: https://issues.apache.org/jira/browse/PDFBOX-5852. I've uploaded the problem pdf as an attachment, and it looks like it went through this way. I re-tested a conversion of this PDF at 650 DPI using PDFBox 2.0.31. Memory usage is still very high. Conversion was completed in 17 minutes. 17 minutes is an improvement on our original tests, but it's still high for a 1 page PDF. I haven't yet tested a conversion using this PDF and PDFBox 3.0.2. I will do this as soon as I get time to write driver code for the PDFBox 3.0.x codebase. Thanks and Regards, Larry Lynn On Fri, Jul 19, 2024 at 12:02 PM Tilman Hausherr <thaush...@t-online.de> wrote: > Hi, > > Yes shading can be very slow, especially at high dpi. The attachment > didn't get through, please upload to a sharehoster or create a ticket. > If you need to register then add a meaningful text, e.g. the subject of > this post so we know you're not a spammer. Also retry with 2.0.31 and > 3.0.2 just to be sure. However I'm pessimistic that this can be fixed. > > Tilman > > On 19.07.2024 19:56, Larry Lynn wrote: > > Hello PDFBox users and maintainers, > > > > We have a PDF that causes performance problems when we use PDFBox to > > convert it to an image with renderImageWithDPI(). We're calling > > renderImageWithDPI() with 650 DPI. I realize this is a very high > > value - we're using it for high fidelity original images that will > > later be downsampled. On my work laptop which has fairly strong > > hardware, the conversion takes 25 minutes and consumes 20GB of > > memory. CPU and memory usage is reduced if we use a lower DPI. > > > > The PDF is 1 page long. It contains type 4 shading / Gouraud free > > form triangle meshes. We've been aware of some performance issues > > with type 4 shading for a little while now, but the PDFs that > > contained the type 4 shading belonged to our customers and we were not > > authorized to share them. We finally found a problem input document > > that is non-sensitive and that we are authorized to share. I've > > attached a copy of the problem PDF to this email. > > > > I searched the archives for the users and the developers mailing list > > and I didn't find anything specifically about this issue. > > I searched through the PDFBox jira tickets and I found a couple of > > tickets that looked similar: PDFBOX-2901 & PDFBOX-4491. PDFBOX-2901 > > seems to most closely describe what we're seeing, but that was closed > > in PDFBox 2.0.0, and our issue still reproduces with PDFBox 2.0.28. > > > > Should I refer this issue over to the developers mailing list or > > create a PDFBox Jira ticket for this? > > > > Thanks and Regards, > > Larry Lynn > > > > -- > > *Larry Lynn* > > **Staff *Software Engineer* > > *Workiva Inc*. > > > > *448 E. Main St, Bozeman, MT, 59715 > > > > * > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail:users-unsubscr...@pdfbox.apache.org > > For additional commands, e-mail:users-h...@pdfbox.apache.org > > -- *Larry Lynn* *Staff Software Engineer* *Workiva Inc*. *448 E. Main St, Bozeman, MT, 59715*
