Re: Possible problem with Gnus

[David Kastrup]

Richard Stallman <address@hidden> writes:

>     The GhostScript option -dSAFER does this.
> 
> Does Emacs pass that argument when it invokes GhostScript?
> 
>                                              But anyway: the current
>     inline display of PostScript images suffers so many problems that it
>     would be a royal mistake to enable it by default.
> 
> If there are bugs in the Postscript support, please start reporting
> them one by one.  This is a feature that is supposed to work,
> and if it doesn't, we should fix it.

It is not a feature that is supposed to work.  From the code in
lisp/gs.el:

;;; Commentary:

;; This code is experimental.  Don't use it.

;;; Code:

[...]

  (unwind-protect
      (let ((file (plist-get (cdr spec) :file))
            gs
            (timeout 40))
        ;; Wait while property gets freed from a previous ghostscript process
        ;; sit-for returns nil as soon as input starts being
        ;; available, so if we want to give GhostScript a reasonable
        ;; chance of starting up, we better use sleep-for.  We let
        ;; sleep-for wait only half the time because if input is
        ;; available, it is more likely that we don't care that much
        ;; about garbled redisplay and are in a hurry.
        (while (and
                ;; Wait while the property is not yet available
                (not (zerop (length (x-window-property "GHOSTVIEW"
                                                       frame))))
                ;; The following was an alternative condition: wait
                ;; while there is still a process running.  The idea
                ;; was to avoid contention between processes.  Turned
                ;; out even more sluggish.
                ;; (get-buffer-process "*GS*")
                (not (zerop timeout)))
          (unless (sit-for 0 100 t)
            (sleep-for 0 50))
          (setq timeout (1- timeout)))

So here we are, in a busy wait loop, hoping that eventually some
GhostScript process will get enough CPU time to release the X resource.

        ;; No use waiting longer.  We might want to try killing off
        ;; stuck processes, but there is no point in doing so: either
        ;; they are stuck for good, in which case the user would
        ;; probably be responsible for that, and killing them off will
        ;; make debugging harder, or they are not.  In that case, they
        ;; will cause incomplete displays.  But the same will happen
        ;; if they are killed, anyway. The whole is rather
        ;; disconcerting, and fast scrolling through a dozen images
        ;; will make Emacs freeze for a while.  The alternatives are a)
        ;; proper implementation not waiting at all but creating
        ;; appropriate queues, or b) permanently bad display due to
        ;; bad cached images.  So remember that this
        ;; is just a hack and if people don't like the behaviour, they
        ;; will most likely like the easy alternatives even less.
        ;; And at least the image cache will make the delay apparent
        ;; just once.

It is clearly documented in the code that the behavior is deficient as
soon as more than single images are concerned.  A separate GhostScript
process gets started for each image that appears on-screen.  Emacs
locks up in busy waiting until the resulting contention of possibly
dozens of GhostScript processes for the respective (GhostView) X
property calms down.  It can't start another process unless the
property has been freed again.  The only platform on which the
postscript device works in the first place is X11.  And there only
marginally.

The sane thing to do is to serialize the whole GhostScript operation
to have at most one GhostScript process running, and to not restart
this process as long as images remain to be rendered.  For this to
work, one has to stop passing the information through an XPixMap but
has to go through a file or pipe.  But file/blocking pipe access
within the display engine is not the hottest idea in the first place.

PostScript image support was the thing that prompted me to create
preview-latex because "it was easy to do so".  The deficiencies in
PostScript support, however, required that even before making the
first public release, preview-latex would have to manage GhostScript
itself to do the rendering.  I reported quite a few problems,
sometimes with patches, before I finally gave up.

There are other considerations making extensive use of PostScript
images a bad idea:

Apart from the lack of sharing resources between images (preview-latex
manages all images from a single LaTeX run in a single GhostScript
session from a single PostScript file it uses intelligently by
interpreting DSC comments like a PostScript previewer does), the
rendering of "postscript" images only starts once they appear
on-screen.  In contrast, preview-latex first deals with on-screen
images.  Once they are dealt with, it reverts to rendering the rest
off-screen.  Since GhostScript converts them all into PNG, the images
actually don't get loaded unless one actually scrolls them on-screen.
Once one does this, however, they are loaded from file.  There is no
necessity for inflating Emacs' memory requirements before such images
get loaded.  preview-latex's way of handling images is convenient, but
it takes up temporary disk space and files.  Managing this disk space
from within the display engine would be awkward, to say the least.

So even if one were to overcome the worst bugs of the postscript image
type implementation, postscript image support would still be bad for
anything but very few images per file.  Scrolling through a buffer
that explodes into rendering at any scroll-up key is not fun.  Been
there, done that.

Perhaps one should warn about this state of affairs in the manual.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum