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: Fri, 06 Feb 2015 12:17:43 +1100 Message-ID: <874mqzvnwo.fsf@building.gnus.org> References: <83lhkkl23i.fsf@gnu.org> <83bnlgkl1s.fsf@gnu.org> <837fw3l7uz.fsf@gnu.org> <54CD4B27.4080201@gmx.at> <874mr6qvi5.fsf@building.gnus.org> <87sieqpfxh.fsf@building.gnus.org> <54CDE908.7050908@gmx.at> <87ioflq0dz.fsf@building.gnus.org> <54CE2187.9070003@gmx.at> <83lhkhiq8t.fsf@gnu.org> <54CE54A3.1020707@gmx.at> <838ughilmo.fsf@gnu.org> <54CE6BD2.8000402@gmx.at> <8361bliin0.fsf@gnu.org> <83386piiby.fsf@gnu.org> <87oap9yoti.fsf@building.gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423185585 11576 80.91.229.3 (6 Feb 2015 01:19:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Feb 2015 01:19:45 +0000 (UTC) Cc: martin rudalics , Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 06 02:19:40 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 1YJXa7-0004Cn-RX for ged-emacs-devel@m.gmane.org; Fri, 06 Feb 2015 02:19:39 +0100 Original-Received: from localhost ([::1]:46257 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJXa7-0006lQ-5g for ged-emacs-devel@m.gmane.org; Thu, 05 Feb 2015 20:19:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJXa3-0006lD-0l for emacs-devel@gnu.org; Thu, 05 Feb 2015 20:19:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJXZy-0006uq-16 for emacs-devel@gnu.org; Thu, 05 Feb 2015 20:19:34 -0500 Original-Received: from smtp.syd.comcen.com.au ([203.23.236.77]:1986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJXZx-0006tw-FN; Thu, 05 Feb 2015 20:19:29 -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 t161Hmld015478; Fri, 6 Feb 2015 12:17:48 +1100 (EST) In-Reply-To: (Stefan Monnier's message of "Thu, 05 Feb 2015 09:01:38 -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.077, required 4, AWL 0.08, BAYES_05 -0.10, 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:182488 Archived-At: Stefan Monnier writes: > IIRC this "standard width of the default font" matches the unit assumed > by `vertical-motion', so it should indeed work (IOW, vertical-motion > will do the equivalent of multiplying its arg by (frame-char-width) > internally to get a pixel size). Oh, I see. Thanks. I've been doing some benchmarking to get a feel for the speed of `vertical-motion'. shr-tag-body 100 2.2069731249 0.0220697312 shr-fold-lines 100 1.2538841410 0.0125388414 shr-fold-line 1500 1.2457802040 0.0008305201 shr-goto-pixel-column 5000 1.1738643779 0.0002347728 `shr-goto-pixel-column' is just a call to `vertical-motion' separated out to see how much time it takes. So, basically, folding 1500 lines takes 1.24s, of which 1.17s is spent in `vertical-motion' (plus function call overhead). (It's called a lot of times because the lines are very long and need to be filled more than once.) (benchmark-run 5000 (vertical-motion (cons (/ 700 (frame-char-width)) 0))) => (0.942894006 2 0.05716983599999992) But it's all kinda moot since `window-text-pixel-size' doesn't work on non-displayed buffers (yet). But if that could be made to work somehow (Eli seemed to have an idea here?), I wonder whether a faster interface would be to have a version of `window-text-pixel-size' that returns a vector of glyph sizes. Then that vector could be used both for going to a column (by just adding until we get to the required pixel count) as well as for computing the displayed width of each line. And this would be only one call to this new function per each (long) line instead of repeatedly calling `vertical-motion' after each line break has been inserted, so it may be faster. The glyph width vector would also allow caching of the data, which would speed up multi-column computation, where each text line is usually folded more than once to reach an optimal layout. Of course, computing the vector may be unreasonably slow. Or not. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/