moraes@cs.toronto.edu (Mark Moraes) (09/14/90)
grunwald@foobar.colorado.edu (Dirk Grunwald) writes: >how does 'ralpage' compare to ghostscript 2.0 (available on prep.ai.mit.edu). gs2.0 was able to preview some things that ralpage didn't. (dvi2ps output, including the psfig/TeX manual), and MacDraw output. gs2.0 croaked a few pages into the psfig/troff manual (output of transcript2.1 psdit), but ralpage was so slow on the images on the first page, I gave up on it. gs2.0 doesn't like something in the starlines example (possibly the fact that I don't have the fonts installed -- using ugly_r.gsf only) On some things, gs2.0 is much faster. It generally seems to use less CPU time, but sometimes seems to use more real time, perhaps because it's doing things that the X server does more slowly? Some timings on an SGI 4D/240 driving a 3/50 display (an R4 server, compiled with gcc): mooreform.ps: gs: real 36.7 user 3.3 sys 1.2 ralpage: real 1:05.4 user 17.6 sys 3.2 raygun2 gs: real 55.4 user 2.7 sys 1.7 ralpage: real 59.4 user 4.2 sys 2.0 a manual page, formatted with ditroff/transcript2.1 gs: real 16.3 user 1.2 sys 0.5 ralpage: real 9.1 user 3.7 sys 1.4 All in all, this release of Ghostscript is an amazing improvement over the last version. Mark.
grunwald@foobar.colorado.edu (Dirk Grunwald) (09/15/90)
One thing that gs2.0 X previewer does do it paint to both a pixmap and the display. That's kind of redundant, but prompts the question (which will show my X ignorance): How does one making ones own backing pixmap that works like backingstore? E.g., I can specify a backing pixmap for a window, but if portions of that window are obscured, the backing pixmap isn't painted properly. Likewise, I can paint into a pixmap and update the window with the pixmap. This then requires hueristics to determine how often to update the window. I've been wondering how to specify this for some time. I ran into this in 'texx' eons ago.
mouse@LARRY.MCRCIM.MCGILL.EDU (09/20/90)
> One thing that gs2.0 X previewer does do it paint to both a pixmap > and the display. That's kind of redundant, Not entirely; it makes handling Expose events much simpler. > but prompts the question [...]: > How does one making ones own backing pixmap that works like > backingstore? It's not really difficult, but it's a bit tedious. Just create the pixmap, and then to draw something do - draw it to the pixmap - set the window's background to be the pixmap - draw it to the window The order is necessary to avoid races with exposures, and the constant resetting of the window's background is necessary because the server is allowed to make a copy of the pixmap when you set the background. (If the server is copying the pixmap, this is also likely to be slow.) I would like to see a something that could be passed in place of the current backing-store hint that says "I want backing-store, and give me an error if you can't commit to doing it" instead of the current scheme, which allows the server to decommit backing-store at any time for any reason. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
grunwald@FOOBAR.COLORADO.EDU (09/20/90)
right, 'gs' does this to avoid exposure events, and you could probably increase display speed 2x by drawing to the pixmap and then displaying that. In texx, I attempted to keep track of exposure events to determine if the window was exposed - if it wasn't, you drew to the window (end eventually copied to the pixmap) else you drew to the pixmap and then then window. Very messy, and it would fail if you obscured it in mid display. Having an explicit backing store would be very useful in these cases.