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: Thu, 30 Apr 2020 14:50:16 +0200 Message-ID: <20200430125016.GB1444@tuxteam.de> References: <20200429171619.GB20842@tuxteam.de> <83imhixkva.fsf@gnu.org> <20200429185128.GA27164@tuxteam.de> <83ees6xggr.fsf@gnu.org> <20200429190854.GC27164@tuxteam.de> <83a72uxffz.fsf@gnu.org> <20200429195930.GA29703@tuxteam.de> <20200430065558.GA21455@tuxteam.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="34762"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 30 14:53:44 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 1jU8hE-0008wX-FJ for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 14:53:44 +0200 Original-Received: from localhost ([::1]:56890 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jU8hD-0007fp-Ex for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 08:53:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41164) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jU8gK-0005nF-8V for emacs-devel@gnu.org; Thu, 30 Apr 2020 08:52:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jU8gD-0000EL-MR for emacs-devel@gnu.org; Thu, 30 Apr 2020 08:52:47 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:33635) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1jU8dw-0006r7-KE; Thu, 30 Apr 2020 08:50:21 -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=Btia3s35bKug0B0qifXFtmulIyoP6KTOlBxKGn8KOsE=; b=QX078s47vTpclHB6kCuxsNWhZur+X5uUWWl/74xCYoaeFeeD8t9BvarTFZrES2hQVgW8eWB5dWBL+KaP0oMrZ992dWZIaYEgaA+MCEMAUE7UXyRVuUuE6Nv4i70DEefB4pJauekHhq00fylFr3jyLurvLnB8CHqbliKnancKyI7Yy6ad0qkWJNDoSWRwq2uHlOYFxVM++WVT+FEJYhmPv9eCcmE5nJ1rZ7OxEybMgRhi1DS6LhGMUgqy/gCit+8s6lRrjtRS+r+1zK9FOts8pP5AN30ej/ixn+aB/uN5CVGhO2+ecbhPo3bhF/OLOpFTYUj/cFTHUZYWHyK1ssyDwA==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1jU8ds-0000lL-Vo; Thu, 30 Apr 2020 14:50:17 +0200 Content-Disposition: inline In-Reply-To: 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/30 08:38:55 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:248228 Archived-At: --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 30, 2020 at 08:03:35AM -0400, Stefan Monnier wrote: > > This is sounding more and more like a compositor :-) >=20 > Yes, the combination of the glyph matrix and the canvas is done by > "a compositor", indeed. But it's a kind of "trivial" version of > a compositor, and it's a very small part of the work (the work taking > place mostly on the canvas side where we'll need to draw at positions > that depend on the glyph matrix). Yes, one would probably want to anchor a graphics object to some position in the (text) buffer. > > Nit: perhaps we'd like to have pics below as well as above text. >=20 > Not sure if the benefit is worth adding complexity for that. > But maybe it's easy and natural to make the layering between glyph > matrix and canvas into an arbitrary stack of layers. AFAIK Cairo supports painting on layers; so each graphics object could carry a layer (encoded e.g. as an int) and drawing operations could proceed sorted by that. > E.g. I could imagine a design where windows can display a stack of > buffers layered one on top of the other (where typically only one of > them contains text and the rest only contains canvas objects). > But "synchronizing" the canvas in one buffer with the text in the other > buffer would likely be more difficult than if we add a canvas "overlay" > directly to the buffers. I envision the thing rather as a collection of graphics objects which are rendered to the same surface as the text. The Cairo backend makes that easy, but I don't see why a plain X backend would prevent that either (I have no idea about how things are on Windows or Mac). Cheers -- tom=C3=A1s --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAl6qyYgACgkQBcgs9XrR2kYoQwCfQT3mKs2lmhX+ZawKwozOHqVE HUoAn3v3PxKAGKNNFpnFJ5oyoTzxpWjk =tpo9 -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc--