Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 5.1.1
-
Fix Version/s: 6.0
-
Component/s: Core/Parsing, Core/Rendering
-
Labels:None
-
Environment:any
Description
A client has sent in a architecture PDF that has a very large number of q and Q operators in it and our restore method (Q) is taking up about 50 seconds of time just doing Area equals calculations.
In the past we have tried to optimize this by using the clip's bounds rather then area. I would like to revisit this and try to figure out why previous approaches have yielded regressions.
In the past we have tried to optimize this by using the clip's bounds rather then area. I would like to revisit this and try to figure out why previous approaches have yielded regressions.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Marking as resolved for now. Improvements have been made but still no magic bullet for very complex paints.
Show
Patrick Corless
added a comment - Marking as resolved for now. Improvements have been made but still no magic bullet for very complex paints.
Marking as closed
Show
Patrick Corless
added a comment - Marking as closed
If we don't do the area clip comparison then we push all the clips into the painting pipeline and the render time is even longer as setting this large number of clips takes even longer then then comparing them.
I've checked in experimental code on the 5.0.1 branch that can be enable with the system property org.icepdf.core.quickclip=true. When enabled a QA run results in a just a handful of regressions related to clips size. However we have no regressions in the large number or architectural diagrams.