From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Pixel-based display functions Date: Thu, 29 Jan 2015 17:55:48 +1100 Message-ID: <87egqekrd7.fsf@building.gnus.org> References: <878uhrcr5l.fsf@building.gnus.org> <83sifzjflk.fsf@gnu.org> <87fvbyagaw.fsf@building.gnus.org> <83iogujvbq.fsf@gnu.org> <87tx0ee7rf.fsf@building.gnus.org> <83egricpvg.fsf@gnu.org> <87zj97vic8.fsf@building.gnus.org> <83wq4argjp.fsf@gnu.org> <87iofui8vo.fsf@building.gnus.org> <838ugqqczp.fsf@gnu.org> <877fw9dndz.fsf@building.gnus.org> <83a914ozsh.fsf@gnu.org> <874mrb1t62.fsf_-_@building.gnus.org> <87vbjrl49k.fsf@violet.siamics.net> <8361bqogah.fsf@gnu.org> <87k306pfi9.fsf@building.gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422514675 32196 80.91.229.3 (29 Jan 2015 06:57:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Jan 2015 06:57:55 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 29 07:57:50 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YGj2z-0006lZ-ES for ged-emacs-devel@m.gmane.org; Thu, 29 Jan 2015 07:57:49 +0100 Original-Received: from localhost ([::1]:57910 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGj2y-0005tF-Ax for ged-emacs-devel@m.gmane.org; Thu, 29 Jan 2015 01:57:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGj2k-0005sv-Lm for emacs-devel@gnu.org; Thu, 29 Jan 2015 01:57:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGj2f-0002ka-BC for emacs-devel@gnu.org; Thu, 29 Jan 2015 01:57:34 -0500 Original-Received: from smtp.syd.comcen.com.au ([203.23.236.77]:4165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGj2X-0002iI-Lr; Thu, 29 Jan 2015 01:57:22 -0500 Original-Received: from building.gnus.org ([27.96.197.126]) by smtp.syd.comcen.com.au (8.13.4/8.12.9) with ESMTP id t0T6tqZF079313; Thu, 29 Jan 2015 17:55:54 +1100 (EST) In-Reply-To: (Stefan Monnier's message of "Wed, 28 Jan 2015 23:08:55 -0500") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) X-comcen-MailScanner-Information: Please contact the ISP for more information X-comcen-MailScanner: Found to be clean X-comcen-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.096, required 4, AWL 0.01, BAYES_40 -0.01, RDNS_NONE 0.10) X-comcen-MailScanner-From: larsi@gnus.org X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 203.23.236.77 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:181963 Archived-At: Stefan Monnier writes: > Coding it in C can make it faster, but you still have the problem of > laziness (which is a general problem for shr, by the way): how to only > render the displayed part of the HTML document, which is crucial to get > reasonable speed on non-small documents. Well, large pages with simple layouts (i.e., single columns) render with linear speed and aren't generally a major problem. > That's the only I really care about, and I think there's much more of > a chance that we can actually make it work reliably with good speed. > > If we do it using the "general" approach in Elisp, I'm afraid we won't > make it work well enough within the foreseeable future (e.g. remember: > one of the features of current info-mode is that it's very quick, so > a replacement that introduces a 1s rendering delay whenever we switch to > another page won't be good enough). I see no reason why rendering a typical info node should take anything approaching one second. I mean, Emacs can display text fast, and shr can lay out stuff fast. If we had access to the pixel widths in advance of redisplay. (eww uses 0.04 seconds to display a typical Emacs manual node with a fixed-width layout on this laptop, according to `benchmark-run'.) I know nothing about how redisplay works, but would (conceptually) saying to Emacs "hey, render this line" (generally very fast) "but don't display it" (should be instantaneous) "and tell me how long that was" (ditto) make sense? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/