I just realized what MAXEDGE does. You are basically saying that the raster can't be bigger than MAXEDGE x MAXEDGE, and if it is, then you clamp the dimensions.
But - are you scaling the bitmap? Or are you just cropping it? If you are just cropping it, it seems like a better approach would be to adjust the tiling matrix by the amount of the scaling required to prevent the raster from being too big. I just committed more changes to my fork: 1. Refined MAXEDGE clamping to scale both dimensions instead of clamping the long dimension (I think this is a better way to do this - but it feels like we should also be scaling the tiling matrix - see above) 2. Added default MAXEDGE values that depend on the bitness of the JVM. I found that MAXEDGE = 500 worked on 32 bit JVMs (but 650 does *not* work). So setting MAXEDGE to 500 for 32 bit JVMs and 3000 for 64 bit JVMs seems like a pretty decent compromise. I look forward to your thoughts about whether MAXEDGE should produce scaling of the tilematrix (or some other matrix). Hopefully that will be an easy thing for you to comment on. - K Kevin Day *trumpet**p| *480.961.6003 x1002 *e| *ke...@trumpetinc.com www.trumpetinc.com <http://trumpetinc.com/> LinkedIn <https://www.linkedin.com/company/trumpet-inc.>| Trumpet Blog <http://trumpetinc.com/blog/>| Twitter <https://twitter.com/trumpetinc> Proud to be Great Place To Work <https://www.greatplacetowork.com/certified-company/7012667> certified since 2019 On Sun, Nov 7, 2021 at 10:03 PM Kevin Day <ke...@trumpetinc.com> wrote: > Test procedure: > > Open PdfBox Debugger, load PDF, capture render time from label in lower > left corner of window. > > > With PdfBox 2.0.17 - this PDF renders in about 4.8 seconds (but is missing > the colored pattern). > > With PdfBox 3 baseline (no code changes) - this PDF renders in 16.2 > seconds seconds. > > With PdfBox 3 caching changes only (no BigBufferedImage) - this PDF > renders in 14.7 seconds > > > So I have not done any damage, and I've sped it up a little bit. > > > But that's only with a single render. Because printing can involve > rendering many times for banded printing (on my test device, I am seeing > well over 100 bands when printing this sample file), the page level caching > should be substantial (the rendering on your test PDF is so slow that it > almost can't be printed) - it is certainly a huge improvement for my test > document. > > > So I think my improvements to the caching (both the tile cache and adding > caching at the page level) are valid. > > - K > > Kevin Day > > *trumpet**p| *480.961.6003 x1002 > *e| *ke...@trumpetinc.com > www.trumpetinc.com <http://trumpetinc.com/> > LinkedIn <https://www.linkedin.com/company/trumpet-inc.>| Trumpet Blog > <http://trumpetinc.com/blog/>| Twitter <https://twitter.com/trumpetinc> > > Proud to be Great Place To Work > <https://www.greatplacetowork.com/certified-company/7012667> certified > since 2019 > > > On Sun, Nov 7, 2021 at 8:34 PM Tilman Hausherr <thaush...@t-online.de> > wrote: > >> Hi, >> >> I don't have much time right now, but please test your change with the >> file from >> >> https://issues.apache.org/jira/browse/PDFBOX-3688 >> >> Tilman >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org >> For additional commands, e-mail: users-h...@pdfbox.apache.org >> >>
