Bug 691599 - huge performance difference between jpeg and bit device for xl-raster-file
Summary: huge performance difference between jpeg and bit device for xl-raster-file
Status: NOTIFIED LATER
Alias: None
Product: GhostPCL
Classification: Unclassified
Component: PCL interpreter (show other bugs)
Version: master
Hardware: PC Windows XP
: P2 normal
Assignee: Henry Stiles
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-07 13:57 UTC by norbert.janssen
Modified: 2011-10-02 02:35 UTC (History)
1 user (show)

See Also:
Customer: 661
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description norbert.janssen 2010-09-07 13:57:47 UTC
this is a followup on 691512.

The testfile contains 8bitRLEencoded raster images.

Though the MaxRasterBitmap improves the performance of the bit-device (from 15min to 1m46. This is still far away from the time needed for the jpeg-device (11 secs).
Because of our legacy-pdl (prints in 5 secs) this is still a concern for us. (with same testfiles as 691512).

measured relatively (on Cygwin platform):
time ufst-obj/pcl6 -sDEVICE=jpeg -sOutputFile=page%d.jpg -r600 -dNOPAUSE -dMaxRasterBitmap=10000000 VZXP9TJ2.xl 
==> 0m11.639s)

time ufst-obj/pcl6 -sDEVICE=bit -sOutputFile=page%d.ras -r600 -dNOPAUSE -dMaxRasterBitmap=10000000 VZXP9TJ2.xl 
==> 1m145.036s
Comment 1 Henry Stiles 2010-09-09 17:58:25 UTC
Right because the ghostscript graphics library caches patterns fully rendered (halftoned) so peculiar effects can occur when the pattern and halftone interact.  The solution to this was to paint the pattern with width of least common multiple of the halfone width and pattern width see pxink.c for details, this can result in a significantly larger patterns and slower processing times.  If you use the contone code path pxink.c:289 such that the "full width" equals the "repeat width" the performance should be fine. 

The theoretical concerns are real, it is easy to imagine how the halftone screen would be applied incorrectly when tiling an already halftoned pattern, but actual practical problems seem to be rare.  PCL XL FTS 3.0 T421 panel 9 is one of the few good examples I've found.  Also, I am not sure why we haven't seen this problem in postscript or pdf which, as far as I know, neither increase pattern size to avoid this problem.  All leading to the suggestion we could disable the replicating code and document the rare problems that do occur anomalies.

I've copied in Michael Vrhel our color expert, he may have some thoughts.
Comment 2 norbert.janssen 2010-10-19 08:45:58 UTC
(In reply to comment #1)
> Right because the ghostscript graphics library caches patterns fully rendered
> (halftoned) so peculiar effects can occur when the pattern and halftone
> interact.  The solution to this was to paint the pattern with width of least
> common multiple of the halfone width and pattern width see pxink.c for details,
> this can result in a significantly larger patterns and slower processing times.
>  If you use the contone code path pxink.c:289 such that the "full width" equals
> the "repeat width" the performance should be fine. 
> 
> The theoretical concerns are real, it is easy to imagine how the halftone
> screen would be applied incorrectly when tiling an already halftoned pattern,
> but actual practical problems seem to be rare.  PCL XL FTS 3.0 T421 panel 9 is
> one of the few good examples I've found.  Also, I am not sure why we haven't
> seen this problem in postscript or pdf which, as far as I know, neither
> increase pattern size to avoid this problem.  All leading to the suggestion we
> could disable the replicating code and document the rare problems that do occur
> anomalies.
> 
> I've copied in Michael Vrhel our color expert, he may have some thoughts.

I set the limit to 128 (i.s.o. 10000), but this indeed introduces a minor? artefact. Though performance is then as expected. Don't know what is better.
I think that with this job it's hardly visible when printed on paper (but have to check that).
Comment 3 Henry Stiles 2010-11-08 15:35:40 UTC
Resolving to "LATER", Norbert if you want to talk about this more please send me email or reopen the bug.