[jira] [Comment Edited] (PDFBOX-2117) AxialShadingContext is slow

["Tilman Hausherr (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PDFBOX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081952#comment-14081952 ] 

Tilman Hausherr edited comment on PDFBOX-2117 at 8/1/14 6:05 AM:
-----------------------------------------------------------------

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 there yet.


was (Author: tilman):
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)