[jira] [Comment Edited] (PDFBOX-5134) Very slow rendering on PageDrawer.shadingFill
[
https://issues.apache.org/jira/browse/PDFBOX-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305421#comment-17305421
]
Tilman Hausherr edited comment on PDFBOX-5134 at 3/20/21, 1:05 PM:
---
I tested your changes and had many invisible differences, and two slightly
visible (gs-bugzilla687307-2.pdf and PDFBOX-4217-shade_via_1.3_006.pdf). I got
rid of all of them except one (gs-bugzilla689095.pdf, differences are
invisible) with this code in the two context classes:
{code:java}
if (bounds != null)
{
bounds.add(new Point((int) Math.floor(bounds.getMinX())-1, (int)
Math.floor(bounds.getMinY())-1));
bounds.add(new Point((int) Math.ceil(bounds.getMaxX())+1, (int)
Math.ceil(bounds.getMaxY())+1));
} {code}
Another problem was that the rendering tests sometimes froze for a minute, then
went on. Apparently I got rid of that by calling {{dispose()}} on the context
after it's done.
was (Author: tilman):
I tested your changes and had many invisible differences, and two slightly
visible (gs-bugzilla687307-2.pdf and PDFBOX-4217-shade_via_1.3_006.pdf). I got
rid of most of them with this code in the two context classes:
{code:java}
if (bounds != null)
{
bounds.add(new Point((int) Math.floor(bounds.getMinX())-1, (int)
Math.floor(bounds.getMinY())-1));
bounds.add(new Point((int) Math.ceil(bounds.getMaxX())+1, (int)
Math.ceil(bounds.getMaxY())+1));
} {code}
Another problem was that the rendering tests sometimes froze for a minute, then
went on. Apparently I got rid of that by calling {{dispose()}} on the context
after it's done.
> Very slow rendering on PageDrawer.shadingFill
> -
>
> Key: PDFBOX-5134
> URL: https://issues.apache.org/jira/browse/PDFBOX-5134
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
>Affects Versions: 2.0.22, 2.0.23
>Reporter: Oliver Schmidtmer
>Priority: Major
> Labels: optimization, shading
> Attachments: PDFBOX-4217-shade_via_1.3_006.pdf,
> PDFBOX-4217-shade_via_1.3_006.pdf-1.png,
> PDFBOX-4217-shade_via_1.3_006.pdf-1.png-diff.png, Plan zum Testen.pdf,
> gs-bugzilla687307-2.pdf, gs-bugzilla687307-2.pdf-1.png,
> gs-bugzilla687307-2.pdf-1.png-diff.png, image-2021-03-17-20-16-49-221.png
>
>
> The PDF contains many effectively very small shadings, the light cones. As
> the gradient painting for each light cone is applied on the whole image,
> rendering is very slow: 29 of 33 seconds are spent in shadingFill.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-5134) Very slow rendering on PageDrawer.shadingFill
[
https://issues.apache.org/jira/browse/PDFBOX-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304339#comment-17304339
]
Tilman Hausherr edited comment on PDFBOX-5134 at 3/18/21, 6:36 PM:
---
Thanks, I tested this, and hit a few minor problems:
- context.getBounds() can be null
- PDTriangleBasedShadingType is also types 6 and 7, which do not produce a
GouraudShadingContext
Sadly types 6 and 7 are derived from type 4, so for the test I checked the
class name like this \{{shading.getClass().getName().endsWith("4") ||
shading.getClass().getName().endsWith("5")}}.
- in one case, the context is a SoftMask
I avoided all these and all renderings are fine!
Another problem is making stuff public. We usually try to avoid that, because
the more there is public, the more there is a risk of people using the API in
weird ways that we haven't thought about.
was (Author: tilman):
Thanks, I tested this, and hit a few minor problems:
- context.getBounds() can be null
- PDTriangleBasedShadingType is also types 6 and 7, which do not produce a
GouraudShadingContext
Sadly types 6 and 7 are derived from type 4, so for the test I checked the
class name like this \{{shading.getClass().getName().endsWith("4") ||
shading.getClass().getName().endsWith("5")}}.
- in one case, the context is a SoftMask
I avoided all these and all renderings are fine!
Another problem is making stuff public. We usually try to avoid that, because
the more there is public, the more there is a risk of people using the API in
weird ways that we haven't thought about.
> Very slow rendering on PageDrawer.shadingFill
> -
>
> Key: PDFBOX-5134
> URL: https://issues.apache.org/jira/browse/PDFBOX-5134
> Project: PDFBox
> Issue Type: Bug
>Reporter: Oliver Schmidtmer
>Priority: Major
> Labels: shading
> Attachments: Plan zum Testen.pdf, image-2021-03-17-20-16-49-221.png
>
>
> The PDF contains many effectively very small shadings, the light cones. As
> the gradient painting for each light cone is applied on the whole image,
> rendering is very slow: 29 of 33 seconds are spent in shadingFill.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-5134) Very slow rendering on PageDrawer.shadingFill
[
https://issues.apache.org/jira/browse/PDFBOX-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303733#comment-17303733
]
Oliver Schmidtmer edited comment on PDFBOX-5134 at 3/17/21, 9:28 PM:
-
That is correct, the slow painting is Java itself. However, the clipping area
is null and the paint applied to the whole image while those shades are
PDTriangleBasedShadingTypes which only cover a very small area.
For example with the device bounds [x=0,y=0,width=4031,height=2024] a bounding
rectangle, calculated in GouraudShadingContext.setTriangleList, around the
triangles for shading COSName\{Sh0} is only
[x=2916.300048828125,y=897.4940185546875,w=16.97998046875,h=17.0400390625]
Applying a Paint to such a small area should be much faster. I probably need
more time to look into how to calculate that beforehand and setting the
clipping area.
I'm sorry I hadn't already analyzed it that deeply a few hours ago. I only
suspected there should be some way to set a better clipping area for a such
small painted area. :)
was (Author: schmidor):
That is correct, the slow painting is Java itself. However, the clipping area
is null and the paint applied to the whole image while those shades are
PDTriangleBasedShadingTypes which only cover a very small area.
For example with the device bounds [x=0,y=0,width=4031,height=2024] a bounding
rectangle, calculated in GouraudShadingContext.setTriangleList, around the
triangles for shading COSName\{Sh0} is only
[x=2916.300048828125,y=897.4940185546875,w=16.97998046875,h=17.0400390625]
Applying a Paint to such a small area should be much faster. I probably need
more time to look into how to calculate that beforehand and setting the
clipping area.
> Very slow rendering on PageDrawer.shadingFill
> -
>
> Key: PDFBOX-5134
> URL: https://issues.apache.org/jira/browse/PDFBOX-5134
> Project: PDFBox
> Issue Type: Bug
>Reporter: Oliver Schmidtmer
>Priority: Major
> Labels: shading
> Attachments: Plan zum Testen.pdf, image-2021-03-17-20-16-49-221.png
>
>
> The PDF contains many effectively very small shadings, the light cones. As
> the gradient painting for each light cone is applied on the whole image,
> rendering is very slow: 29 of 33 seconds are spent in shadingFill.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
