[
https://issues.apache.org/jira/browse/PDFBOX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-2117:
------------------------------------
Attachment: Shading2Function2domain3.pdf
PDFBOX-2117-068519-ShadingType3.pdf
good_pdfbox-2117-068519-shadingtype3.pdf-1.png
bad_pdfbox-2117-068519-shadingtype3.pdf-1.png
But if I do that, I get the bullets of the file PDFBOX-2117-068519.pdf in the
wrong color.
The mistake that everyone made is to think that calculateInputValues() returns
two values that are valid in a range domain0...domain1. However this is not so,
the values are in a range 0..1, see spec about "subsidiary variable". Because
of that, the non-optimized code has this line before evalFunction():
{code}
float input = (domain[0] + (d1d0 * inputValue));
{code}
See the attached file PDFBOX-2117-068519-ShadingType3.pdf, this is just the
bullet. The "bad" rendering is done with using
{code}
key = (int) ((inputValue - domain[0]) * longestDistance / d1d0);
{code}
The "good" rendering is done using
{code}
int key = (int) (inputValue * longestDistance);
{code}
Note that the "bad" rendering not only has lighter colors, the white sphere
edge is missing as well. Because the white color is at the high keys.
Yesterday while "searching for a solution" I had this code that worked:
{code}
float input = (domain[0] + (d1d0 * inputValue));
key = (int) ((input - domain[0]) * longestDistance / d1d0);
{code}
Then I realized that d1d0 and domain[0] were there twice, and the result after
cleaning up is
{code}
int key = (int) (inputValue * longestDistance);
{code}
The image is still not perfect, but this is a different problem: The light blue
background (in the non optimized version it was a light yellow background) is
probably the result of a wrong decision about how to handle out-of-range
values. It should be white.
BUT you might still be correct about something not being right: the attached
file Shading2Function2domain3.pdf never renders correctly, i.e. not with the
non-optimized versions, and not with the optimized versions. (with my line of
code, it makes stripes; with your line of code, no stripes but it renders as if
the domain was 0..1) I haven't looked closely
> AxialShadingContext is slow
> ---------------------------
>
> Key: PDFBOX-2117
> URL: https://issues.apache.org/jira/browse/PDFBOX-2117
> Project: PDFBox
> Issue Type: Sub-task
> Components: Rendering
> Affects Versions: 1.8.6, 1.8.7, 2.0.0
> Reporter: Petr Slaby
> Assignee: Shaola Ren
> Labels: shading, shadingpattern
> Fix For: 2.0.0
>
> Attachments: 000001_MTEXT_CS6.pdf, AxialShading.patch,
> AxialShading1.patch, AxialShadingContext.java.getrgbimage,
> GWG061_Shading_x1a.pdf, GWG061_Shading_x1a.pdf-1.png,
> GWG061_Shading_x1a.pdf-1.png-diff.png, PDFBOX-2117-068519-ShadingType3.pdf,
> PDFBOX-2117-068519.pdf, PDFBOX-2117-068519.pdf-2-bad.png,
> PDFBOX-2117-068519.pdf-2-good.png, Shading2Function2.pdf,
> Shading2Function2.ps, Shading2Function2domain3.pdf,
> Shading2Function2text.pdf, asy-shade.pdf,
> bad_pdfbox-2117-068519-shadingtype3.pdf-1.png, color_gradient.pdf,
> good_pdfbox-2117-068519-shadingtype3.pdf-1.png, shading_pattern.pdf
>
>
> AxialShadingContext#getRaster() is on top of profiler hot spots in documents
> that use an axial shading. Inside it, the slowest part is calling
> PDColorSpaceRGB#toRGB() and PDFunctionType3#eval() (in this order).
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
