From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: tomas@tuxteam.de Newsgroups: gmane.emacs.devel Subject: Re: Emacs canvas support Date: Wed, 29 Apr 2020 20:51:28 +0200 Message-ID: <20200429185128.GA27164@tuxteam.de> References: <834kt21yyo.fsf@gnu.org> <87zhau1uog.fsf@yahoo.com> <83sggmzjp8.fsf@gnu.org> <87mu6u1tii.fsf@yahoo.com> <83o8raziis.fsf@gnu.org> <877dxy1smz.fsf@yahoo.com> <87o8rae0ao.fsf@randomsample> <83lfmexmfp.fsf@gnu.org> <20200429171619.GB20842@tuxteam.de> <83imhixkva.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="19526"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 29 20:53:15 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jTrpa-0004y5-Ju for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Apr 2020 20:53:14 +0200 Original-Received: from localhost ([::1]:47534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTrpZ-0006yA-J5 for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Apr 2020 14:53:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39434) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTrny-0004j7-RA for emacs-devel@gnu.org; Wed, 29 Apr 2020 14:51:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jTrny-0002Il-Ar for emacs-devel@gnu.org; Wed, 29 Apr 2020 14:51:34 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:59603) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1jTrnv-0002CD-L6; Wed, 29 Apr 2020 14:51:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=It5szTtoRIrXNFrVvM+8ShoVDkvDlaBYzZB9NjOoUwk=; b=B+gqmNwir0nVYFVAp3TzZFC8kBRBN9E2YiBP4bEgmsAS8TC/nsvRfiX5NiEu0l4sys+sbgcp7hC4yKvVBgw3brFacrHxW+Z1b8BwqaGPGKIDioqjMmNLtwWUDDhnTJsVaburUEHwBfZwU4JCFChy5CpAu6lXTtBhcQVyAoA2aZCSA+1wQ5hsPDHmkm5J8RSdA+W1SdZoyNZrbuwft7RzfHf7E0pY0rkKZA+vM0qQ76wuYLOaUNvM8AM8ZMenxkQN+H8qzo0S/Pvm25Fvf0yf3Y29GODN3Z6/V26kuMjrixxOVCeoPE4n8RUpT1FcvjIF+S52OazeWs4GDLa2CB95YQ==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1jTrns-0007Bi-Nd; Wed, 29 Apr 2020 20:51:28 +0200 Content-Disposition: inline In-Reply-To: <83imhixkva.fsf@gnu.org> Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/29 13:16:20 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Received-From: 5.199.139.25 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:248175 Archived-At: --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 29, 2020 at 08:27:53PM +0300, Eli Zaretskii wrote: > > Date: Wed, 29 Apr 2020 19:16:19 +0200 > > From: > >=20 > > > Drawing over normal text, if we don't want to redesign the entire > > > display engine, needs some new kind of "display element" ( a sibling > > > to "character", "image", "stretch", etc.), one that doesn't > > > necessarily have any effect on the metrics of the screen lines it is > > > drawn upon. I'm not sure I have a clear idea about what features such > > > a drawing will need to support, but it could be possible to add such > > > an element with not too much effort. Would someone want to come up > > > with a reasonable list of requirements for such a feature? > >=20 > > That sounds... exciting. Basically, Emacs would have to have a "display > > list" of graphical elements to draw, each one perhaps having a bounding > > box (to discard those from redisplay which aren't currently visible) > > and perhaps a "layer" (more to the background or foreground). >=20 > That's not how Emacs controls what's on display. It basically > represents each window as a 2D array of glyphs, each one of which has > a certain graphical representation. =2E..a display list of sorts. > The representation itself is of > no concern to the display engine (well, almost); the only thing it > cares about is the metrics of each glyph, because that's what it needs > to do layout calculations. A graphical overlay wouldn't have "glyph metrics", the graphical objects would (I think) have "absolute" [1] positions (possibly precalculated by something else). > We need to try to fit into this framework, if possible. I think the "interesting" problem is to know (quickly) which graphical objects intersect the (visible) window -- something graphics programs do as their main job. Cheers [1] Well, absolute is relative ;-) perhaps anchored at some text in the buffer, perhaps anchored to the window... I don't know. -- tom=C3=A1s --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAl6pzLAACgkQBcgs9XrR2kYf5QCfTe2K1heTxSaimZ9svpiWNrqj Et4An1wx6ZdFzknre8gXmz9o/Qlh1gYy =Ky4h -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ--