Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #873

Re: (embarrassingly) simple showpage question

Show all headers | View raw

ken <ken@spamcop.net> wrote:
> john@please.see.sig.for.email.com says...

Okay, I think I've implemented all your suggestions below, and
(just to top-post a scoreboard of all the results) the sequence
of improving file sizes and convert runtimes (on an i7-920) is...
Original
  http://www.forkosh.com/decorative/decofweek.gif
  http://www.forkosh.com/decorative/decofweek.ps
  File size ~5MB, convert time ~6mins.
V2
  http://www.forkosh.com/decorative/decofweek-v2.gif
  http://www.forkosh.com/decorative/decofweek-v2.ps
  File size 350KB, convert time 31secs.
and finally V3 with your suggestions
  http://www.forkosh.com/decorative/decofweek-v3.gif
  http://www.forkosh.com/decorative/decofweek-v3.ps
  File size 194KB, convert time 9.6secs
  (Note: that's with a 4"x4" %%BoundingBox: 0 0 288 288)
In all cases the convert command was,
  convert -transparent "#FFFFFF" -delay 0 -loop 0 input.ps output.gif

Besides downloading those .ps links, I put the cgi online (the
C source will eventually be gpl'ed) at
  http://www.forkosh.com/cgi-bin/stringart.cgi
The %%Title of each .ps file is the ?query_string that generated it.
For example,
  .../stringart.cgi?ps&animation=1&huea=0&hueb=360&hue1=999&hue2=999&
  linewidthpt2=4&papersize=4&papermargin=0
should make your browser prompt you to save stringart.ps,
identical to the decofweek-v3.ps file above.
   If you remove those first two "ps&animation=1&" attributes,
your browser should display the corresponding gif, i.e.,
stringart.cgi will run convert for you and just emit the gif.
In this case, removing "animation=1", just emits
the "last frame", the completed design containing all lines.
(Running convert for animations is disabled due to resources
required, so you can only request the ps file.)

> My suspicion would be that assembling an animated GIF from 100 PNM files 
> is the slow bit, especially if ImageMagick is doing any kind of 
> filtering on the data.
>    A quick test on my (5 year old) PC here ran your v2 test in 18 seconds, 
> producing 100 pages, each of which is 1.5Mb in size. So I'm seeing data 
> produced by GS at ~7MB/second, which isn't bad, though it is slower than 
> I woudld expect. Of course assembling the animated GIF means that 
> ImageMagick has to read 150MB of data and presumably remove the white 
> space.

I tried (on the i7-920)
   gs -q -dQUIET -dBATCH -dNOPAUSE -sDEVICE=pnmraw
      -sOutputFile=decofweek.pnm decofweek.ps
which ran in ~4secs and produced one 144MB output file.
Then convert -switches decofweek.pnm decofweek.gif
still took ~6mins, so you're right that's the "slow bit".

> Two things spring immediatley to mind:
> 
> 1) Reduce the resolution. I can't recall what the default resolution for 
> pnmraw is, and you command line doesn't tell me what's being used.

Still haven't played with the convert -switches mentioned in
the preceding followup to your same post. (I don't think there's
any additional way to affect resolution on "the postscript front"
besides your suggestions below which are all implemented now.)

> 2) Reduce the page size. There's a *lot* of white space on the page, 
> even when you consider the total drawing rather than each individual 
> page. You don't seem to be setting the page size anywhere, but relying 
> on the default. Moving the drawing so that the lower and left parts of 
> the drawing are at x=0 and y=0, and then reducing the media size so that 
> the media is just large enough to contain the drawing woudl reduce the 
> amount of white space. This would reduce the amount of data GS produces 
> and also (of course) the amount of data ImageMagick has to process.

I believe that's all done in decofweek-v3 (the "papersize" and
"papermargin" attributes in the example query_string above), and
probably accounts for all the v2-to-v3 improvement cited above.

> On the PostScript front, you should bind your procedures. You clearly 
> don't intend to have them change at run-time (which is the reason why 
> you wouldn't bind them). Bound procedures run faster, as the interpreter 
> doesn't have to lookup and execute the PostScript each time. Doing this 
> with your file reduced the execution time from 18 secs to 3 seconds on 
> my PC. Your mileage may vary of course.

Did that, too, but I noticed absolutely zero runtime change
(~4secs before, ~4secs after). Go figure.
Thanks so much, Ken,
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

Back to comp.lang.postscript | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

(embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-08 04:58 +0000
  Re: (embarrassingly) simple showpage question ken <ken@spamcop.net> - 2012-08-08 07:59 +0100
    Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-08 08:54 +0000
      Re: (embarrassingly) simple showpage question ken <ken@spamcop.net> - 2012-08-08 10:17 +0100
        Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-08 10:08 +0000
          Re: (embarrassingly) simple showpage question tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2012-08-08 22:07 -0400
            Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-09 05:40 +0000
              Re: (embarrassingly) simple showpage question ken <ken@spamcop.net> - 2012-08-09 08:44 +0100
                Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-09 09:38 +0000
                Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-10 06:24 +0000

csiph-web