From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: redisplay system of emacs Date: Fri, 29 Jan 2010 20:03:47 +0900 Message-ID: References: <27349166.post@talk.nabble.com> <83bpge50k5.fsf@gnu.org> <87vdem8gly.fsf@catnip.gol.com> <87k4v1xm4l.fsf@gmail.com> <87ljfhkyg2.fsf@lola.goethe.zz> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1264763055 15128 80.91.229.12 (29 Jan 2010 11:04:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jan 2010 11:04:15 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 29 12:04:12 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Naoe4-00027X-7J for ged-emacs-devel@m.gmane.org; Fri, 29 Jan 2010 12:04:12 +0100 Original-Received: from localhost ([127.0.0.1]:38951 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Naoe3-0006m7-PL for ged-emacs-devel@m.gmane.org; Fri, 29 Jan 2010 06:04:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Naodv-0006l8-Vr for emacs-devel@gnu.org; Fri, 29 Jan 2010 06:04:04 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Naodr-0006kp-B8 for emacs-devel@gnu.org; Fri, 29 Jan 2010 06:04:03 -0500 Original-Received: from [199.232.76.173] (port=46357 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Naodr-0006km-4c for emacs-devel@gnu.org; Fri, 29 Jan 2010 06:03:59 -0500 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.193]:61072) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Naodm-0007Xl-MH; Fri, 29 Jan 2010 06:03:55 -0500 Original-Received: from relay31.aps.necel.com ([10.29.19.54]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o0TB3mUX029651; Fri, 29 Jan 2010 20:03:48 +0900 (JST) Original-Received: from relay31.aps.necel.com ([10.29.19.20] [10.29.19.20]) by relay31.aps.necel.com with ESMTP; Fri, 29 Jan 2010 20:03:48 +0900 Original-Received: from dhlpc061 ([10.114.114.42] [10.114.114.42]) by relay31.aps.necel.com with ESMTP; Fri, 29 Jan 2010 20:03:47 +0900 Original-Received: by dhlpc061 (Postfix, from userid 31295) id 9BEDC52E1FC; Fri, 29 Jan 2010 20:03:47 +0900 (JST) System-Type: x86_64-unknown-linux-gnu Blat: Foop In-Reply-To: (Lennart Borgman's message of "Fri, 29 Jan 2010 11:23:43 +0100") Original-Lines: 45 X-detected-operating-system: by monty-python.gnu.org: Solaris 8 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:120641 Archived-At: Lennart Borgman writes: >> Uh, Emacs needs to work without noticeable delays and with syntax >> highlighting for documents of _book_ size, easily containing thousands >> of pages. > > Is this necessarily related to the display engine? Different display engines models are affected differently by changes in document size. Mozilla's model, where the _entire document_ is converted into an internal "layed-out-document" data structure, and then that is rendered, and which is mainly targeted at documents of "reasonable" length but with complex layout requirements (web pages), is pretty likely to have an unacceptably high overhead (time and memory used by the layed-out-document) for extremely large documents. Emacs, which doesn't maintain a separate "layed-out-document" data structure at all, and mainly just worries about rendering what's on the screen from the raw document, has a very different set of tradeoffs. Now, it's certainly _possible_ that mozilla actually contains special code to deal with very-large-but-very-simple document structures, and use a different method with different tradeoffs to render them, but... it seems unlikely , and AFAIK, it doesn't. [but of course, this "special" code would more or less just be an implementation of what Emacs does already!] It's also _possible_ that mozilla's algorithms and data-structures are so incredibly fast and efficient that this overhead is acceptable even for extremely large documents on modern machines. Judging from the observed performance of e.g. firefox on large but simple web pages, though, this also seems pretty unlikely. [Emacs of course also does some processing that is proportional to document length, e.g., coding/decoding, and at the most basic, I/O... however such processing is likely to be much simpler/faster (and memory efficient) than what Mozilla has to do layout the document for display.] -Miles -- Friendless, adj. Having no favors to bestow. Destitute of fortune. Addicted to utterance of truth and common sense.