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
