From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Possible problem with Gnus Date: 13 May 2004 19:25:44 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040509230720.GB20485@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084469661 9603 80.91.224.253 (13 May 2004 17:34:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 13 May 2004 17:34:21 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 13 19:34:07 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOK5v-0000u3-00 for ; Thu, 13 May 2004 19:34:07 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOK5v-0003FK-00 for ; Thu, 13 May 2004 19:34:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOJzc-0003ZP-3m for emacs-devel@quimby.gnus.org; Thu, 13 May 2004 13:27:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BOJzX-0003Xl-20 for emacs-devel@gnu.org; Thu, 13 May 2004 13:27:31 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BOJz0-0003ON-VN for emacs-devel@gnu.org; Thu, 13 May 2004 13:27:30 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOJy3-00038z-4s for emacs-devel@gnu.org; Thu, 13 May 2004 13:25:59 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BOJxv-0005RO-LF; Thu, 13 May 2004 13:25:52 -0400 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 122 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23333 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23333 Richard Stallman 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