Will you accept my code changes to have different maxedge values for 32 bit vs 64 bit?
On Mon, Nov 8, 2021, 12:51 AM Tilman Hausherr <thaush...@t-online.de> wrote: > Am 08.11.2021 um 06:38 schrieb Kevin Day: > > 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. > > It crops. It is of course sometimes a terrible solution. I did try > scaling but wasn't successful but maybe you will. > > Tilman > > > > > > > > > > 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 > >>> > >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: users-h...@pdfbox.apache.org > >
