Bug 692249 - Transparency blending is slow.
Summary: Transparency blending is slow.
Status: RESOLVED DUPLICATE of bug 691114
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: master
Hardware: PC All
: P4 normal
Assignee: Michael Vrhel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-01 14:48 UTC by Robin Watts
Modified: 2016-10-13 18:49 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Watts 2011-06-01 14:48:58 UTC 
Created attachment 7557 [details]
57652.pdf

Enhancement bug spun out of bug 692019. The excessive memory use seen in 692019 has gone (thanks to the pattern clist work), but we remain slower than Acrobat.

Profiles suggest that pdf14 blending is taking most of the time.

The command line in question is:

 gs -sDEVICE=tiff24nc -o /dev/null -r300 57652.pdf
Comment 1 Ray Johnston 2011-06-01 18:16:11 UTC 
Note that we have several ideas for improving transparency performance, so
this bug should probably be closed as a duplicate and the attachment
added as a reference to existing bug(s).

The ideas I am aware of are:
   1) use SSE (or other SIMD) code for the blending loop
   2) use chunky pixels instead of planar buffers
   3) collect actual area painted transparently during clist writing so
      that the bbox can be minimized. Paint outside the transparent area
      (alpha == 0 or alpha ==1) using faster painting.
   4) Use fast code more often for type 2 patterns

How much these will help is not known, but (1) is likely to be significant on
CPU's that have the instructions.

The bugs I know of are:

Bug 691114
Bug 691607
Bug 691900
Comment 2 Michael Vrhel 2016-10-13 18:49:54 UTC 

*** This bug has been marked as a duplicate of bug 691114 ***