From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Pixel-based display functions Date: Sat, 07 Feb 2015 14:20:15 +0200 Message-ID: <83lhk9c3r4.fsf@gnu.org> References: <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> <874mqzvnwo.fsf@building.gnus.org> <83h9uzeb4a.fsf@gnu.org> <87bnl7jrr7.fsf@building.gnus.org> <831tm3dt8u.fsf@gnu.org> <87k2zvgj4d.fsf@building.gnus.org> <83siejcahb.fsf@gnu.org> <83sieiar6i.fsf@gnu.org> <87lhkaaq4n.fsf@building.gnus.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423311655 31813 80.91.229.3 (7 Feb 2015 12:20:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Feb 2015 12:20:55 +0000 (UTC) Cc: rudalics@gmx.at, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 07 13:20:55 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 1YK4Na-00039H-Qm for ged-emacs-devel@m.gmane.org; Sat, 07 Feb 2015 13:20:54 +0100 Original-Received: from localhost ([::1]:52587 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK4Na-0001rx-8D for ged-emacs-devel@m.gmane.org; Sat, 07 Feb 2015 07:20:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK4NA-0001rn-2W for emacs-devel@gnu.org; Sat, 07 Feb 2015 07:20:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YK4N6-000328-HM for emacs-devel@gnu.org; Sat, 07 Feb 2015 07:20:28 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:38330) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK4N6-00031s-9R for emacs-devel@gnu.org; Sat, 07 Feb 2015 07:20:24 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NJE00F00HTHSV00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 07 Feb 2015 14:20:17 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJE00F9YI9STY00@a-mtaout22.012.net.il>; Sat, 07 Feb 2015 14:20:17 +0200 (IST) In-reply-to: <87lhkaaq4n.fsf@building.gnus.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:182593 Archived-At: > From: Lars Ingebrigtsen > Cc: rudalics@gmx.at, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > Date: Sat, 07 Feb 2015 22:59:52 +1100 > > Eli Zaretskii writes: > > > A few preliminary questions about this: > > > > . Is it good enough to handle only a single physical line, starting > > from a given POSITION argument and ending at the first newline that > > follows POSITION? (Handling of additional lines will then have to > > be done in Lisp.) > > If this can be done as fast as collecting the line data in C, that would > be fine. What do you mean by "collecting the line data"? > But I would assume that there's quite a lot set-up overhead > before getting started. For instance, calling `window-text-pixel-size' > ten times over separate lines instead of once on a region is way slower. > > But if there's no setup overhead, then doing it per line basis would be > fine. There's always setup overhead when using the display engine subroutines. Whether it's significant in this case, remains to be seen. Since handling more than one line needs the one-line case as its workhorse anyway, I think I will go with that first, and then extend it if it's not fast enough for many lines. > > . What to assume/do with the various display features, like overlay > > and display strings, images, align-to space specs, line-prefix, > > etc., that can be pertinent to the portion of text being processed? > > The easiest alternative is to handle them "as usual" in redisplay, > > i.e. the corresponding glyphs will be produced and included in the > > return value. Is that OK? > > Yes, including all that stuff is necessary to do the line filling. Do you need to know the "type" of each glyph as well, or are dimensions enough? > > If not, what else is needed for these > > use cases? (Note that if a display or overlay string includes > > newlines, this means the result could span multiple screen lines -- > > will that be a problem?.) > > Hm... I hadn't though of that. Well, in the shr case, there are no > overlays at all, and the only display strings are `align-to' one, I > think... Well, align-to will produce a stretch glyph that has no underlying character -- do you care about that? And then what about images?