Bug #780

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

Added by James about 4 years ago. Updated about 4 years ago.

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

100%

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

Description

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}!
FO
% 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.

History

#1 Updated by Paul about 4 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 about 4 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 about 4 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 about 4 years ago

  • Status changed from Resolved to Closed

Closing this as fixed.

Also available in: Atom PDF