Bug #780

psxy generates unnecessarily large .ps file with many entirely clipped polygons

Added by James over 3 years ago. Updated over 3 years ago.

Status:ClosedStart date:2015-10-03
Priority:NormalDue date:
Assignee:Paul% Done:


Target version:Candidate for next minor release
Affected version:5.2-svn Platform:


I'm plotting a large number of polygons, many of which lie outside the clip region. This results in a lot of spurious postscript commands:

% Segment header: -Z336.447
{1 0.769 0 C} FS
% Temporarily set FO to P for complex polygon building
/FO {P}!
% Perimeter polygon for fill only
% Reset FO and fill the path
/FO {fs os}!
% etc.

I've dug into the code and found that the redefinition of FO is coming from GMT_geo_polygons.

While this isn't a general solution, moving the redefinition into GMT_geo_polygon after the clipping check allows me to generate plots in about half the time. Removing the redefinition of FO entirely allows me to generate plots in about 1/6th of the time.

Further, it would be even better if we didn't set the fill color for an entirely clipped polygon, too.

Associated revisions

Revision 14952
Added by Paul over 3 years ago

Reduce PS commands when polygon is clipped away, see issue #780


#1 Updated by Paul over 3 years ago

  • Status changed from New to In Progress

Eliminating unncessesary commands in the PS is a worthy goal, and we will have a look. However, I am curious how many polygons you have. Each clipped polygon would write
/FO {P}! /FO {fs os}! FO
to the file that we should ry to exclude [the rest are comments that by default is off]. How do you get a factor of 6? Are you saying the unnecessary commands are slowing down ghostscript?

#2 Updated by Paul over 3 years ago

  • Status changed from In Progress to Resolved
  • Assignee set to Paul
  • Target version set to Candidate for next minor release
  • % Done changed from 0 to 100

I've avoid using GMT_geo_line and rewritten the polygon routines so that we only write those commands when the polygon is inside the region. in r14952 (GMT 5.2), let me know if other issues.

#3 Updated by James over 3 years ago

Yes, I should have been clearer: the slowdown comes when running ps2pdf. Thanks for the quick turnaround, I will try this out and let you know. I'm plotting heatmaps for data on arbitrary 2D meshes, the largest of which have about 8 million cells.

#4 Updated by Paul over 3 years ago

  • Status changed from Resolved to Closed

Closing this as fixed.

Also available in: Atom PDF