From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Emacs canvas support Date: Thu, 30 Apr 2020 16:58:10 +0200 Message-ID: References: <875zdikdge.fsf.ref@yahoo.com> <875zdikdge.fsf@yahoo.com> <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> <83h7x2xke8.fsf@gnu.org> <83v9lhvyy8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="44917"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: tomas@tuxteam.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 30 16:58:52 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 1jUAeJ-000BUf-D2 for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 16:58:51 +0200 Original-Received: from localhost ([::1]:35612 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUAeI-0008QG-Fh for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 10:58:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37428) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUAdl-00080x-8m for emacs-devel@gnu.org; Thu, 30 Apr 2020 10:58:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUAdj-0000oX-J1 for emacs-devel@gnu.org; Thu, 30 Apr 2020 10:58:16 -0400 Original-Received: from mail-oln040092074066.outbound.protection.outlook.com ([40.92.74.66]:7398 helo=EUR04-DB3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUAdi-0000oD-V5; Thu, 30 Apr 2020 10:58:15 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e1ZRRfUIUY+3K40g54VjfLXkKfjcznjzX//i4ATv1SR/BH8xDxwd14yfkAt7BOCxNa1KRhWSDUIGLGRXAZKCHoMYXHVRMItnNtbW9RtfIrBqC4vuhpamylkP5o/VAC0YeUY+hCNm9NJJAWvZP1NplH3KeKwXdeTJ+Hfb/vI3+DfgV3rKuphpNzczcOnMTbgFARlN7gKgxcu2F0PkbJjaA13eotlvhqCEyVfMAP480/bUyXFOTIgYrxWe2PFriwnLMidYTujNWmbsz66XqHysNzDVCMGrpN1Uo7Vv/HN6iKN4jKBxuhkHoWpU92AuwQkw7pgD14bBfPJS+L8U4FfUpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CkjpW8OiKExE/FlPTk1im9x3JQtugB3ZzCRk3UtR4oU=; b=Y4OpVys/bPw5tvsKU+b8b03xbsnfUIWMJFCP41WoDd54PLj2dxAfB9XW6ltx1Z6Ff71tgW1XCqXQkk60SW8PW0pEPW3NdxPQz+/2i9CvHBAw/Hw9w36o/k0QfuXN1g7DZApgOxJTY9hmJy8TzPAglu1y7vq75opvzgfJ+jzK0K/Z6MWgxnJU1kyVkQLHynnAo+i+eCxp3S11DwQaHg+EzLq/TZoxDdFOIarOB9hwKYAF73GvwrCJ7NXV+ExVYUrPxLfO1XVcQDT3D8iNOLDduznrvBg5akfmhW03dJQK57DzEuLUaaXV4FcA6eAEynhFuijrkbLxxVwSVCOyhDGrwQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=live.com; dmarc=pass action=none header.from=live.com; dkim=pass header.d=live.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CkjpW8OiKExE/FlPTk1im9x3JQtugB3ZzCRk3UtR4oU=; b=qM0NjxEvwUUMpSGxHIRfWwM8CC9sJp+dlS2y4bb/h7KSkBvyeqAAckgmQBISjzqFHnI80n1Yqs64K/R4Q3bmZjdXInAfl1eYpXxOQgtrsKkxfMKiBVuIlhXW4doAYRwE9z7LqSRxrIkvCY3kMbMlqW+btoA7/GOSiXtKQTFCw4pbXbfphcjbC0+OGYfFQZsP5R6o6AltzpWKUfseGmFhNEBzq4A74iKmSuZyu4lyKz0acs2AGjz/rdopfoA6FYQZUKtecp7iJpONh9cgLH9NCTMCD3a1eSXVExIEKwKJDw9WmT7yVgplPsKji6xV8T8RrkPJxjj2d07/sM6BVz+FmQ== Original-Received: from VI1EUR04FT035.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0e::53) by VI1EUR04HT068.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0e::338) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Thu, 30 Apr 2020 14:58:11 +0000 Original-Received: from AM0PR06MB6420.eurprd06.prod.outlook.com (2a01:111:e400:7e0e::45) by VI1EUR04FT035.mail.protection.outlook.com (2a01:111:e400:7e0e::160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19 via Frontend Transport; Thu, 30 Apr 2020 14:58:11 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:BB85807E666803DC8C2A440A1151DE7F1A090748850BB44AAAC6A7CAA497CC65; UpperCasedChecksum:5FCDDC6D1B1D265CDE1E58010D9DC479C968DAF166E540414E5B5AFCDFD4A460; SizeAsReceived:7921; Count:48 Original-Received: from AM0PR06MB6420.eurprd06.prod.outlook.com ([fe80::849f:536a:6aab:16]) by AM0PR06MB6420.eurprd06.prod.outlook.com ([fe80::849f:536a:6aab:16%5]) with mapi id 15.20.2937.020; Thu, 30 Apr 2020 14:58:11 +0000 In-Reply-To: <83v9lhvyy8.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 30 Apr 2020 17:18:55 +0300") X-ClientProxiedBy: AM6P195CA0005.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:81::18) To AM0PR06MB6420.eurprd06.prod.outlook.com (2603:10a6:208:1a2::19) X-Microsoft-Original-Message-ID: <87d07pqav1.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from pascal.homepc (90.230.29.56) by AM6P195CA0005.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:81::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20 via Frontend Transport; Thu, 30 Apr 2020 14:58:11 +0000 X-Microsoft-Original-Message-ID: <87d07pqav1.fsf@live.com> X-TMN: [PuyWW6R3c9YeQWN/6wwtVUlSmw+Lovp2] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 305ff9e9-ffef-456d-ca98-08d7ed16e6f0 X-MS-TrafficTypeDiagnostic: VI1EUR04HT068: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ISVEk/HvjA9MV7JSSKW23maaGJZdWP7ef+1y7e9n3xwQU11mNlGsoVIqvX63KIRUt7PenawLJs/JTpuWyVeEnt6XOoc8wF42ZaqRvHhguoDl9J8wYzOlKmpkokZEV2eSSDmYYp7fXmLex66DFslT1K8c7bNo6ZnD86s9upWkv+H3OGJmbObPtU/zf7EN0yI3FWVshiQyjB22f5+zJ0spmw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR06MB6420.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; X-MS-Exchange-AntiSpam-MessageData: nrg/2gJo+9WfSNWj2UPJfN+/AXVSnXKCP7WEVo6ksijMn9RCSWwQuDyv51FnGJ51rHK5KATys7AVlU/U3smHR0oS7V+pRG4IShtvc0nL8RoTTV45lbS5ZGitHf7qgWIAbPQlNt5qbxKzOb+9SLp6NQ== X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-Network-Message-Id: 305ff9e9-ffef-456d-ca98-08d7ed16e6f0 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Apr 2020 14:58:11.9312 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1EUR04HT068 Received-SPF: pass client-ip=40.92.74.66; envelope-from=arthur.miller@live.com; helo=EUR04-DB3-obe.outbound.protection.outlook.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/30 10:58:12 X-ACL-Warn: Detected OS = Windows NT kernel [generic] [fuzzy] X-Received-From: 40.92.74.66 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:248244 Archived-At: Eli Zaretskii writes: >> From: Arthur Miller >> Date: Thu, 30 Apr 2020 15:11:10 +0200 >> Cc: tomas@tuxteam.de, emacs-devel@gnu.org >> >> I have a question here about display: when lisp engine decides to draw >> the display, how difficult would it be to add a callback for pre- and >> post render? > > I don't think I understand the question. It is trivial to add a call I am probably not so clear in my writing, but what I mean is, can it be impelemnted as a hook/callback, to enter same redisplay machinery several times. As you described in other mails how redisplay is figuring out what draw, everything has to come from buffers that are essentially glyph matrices etc. Whatever entry in that machinery is now, can't we just have a list of hooks that each call into that machinery? Normally there would be just one such so Emacs work as it is now, but user could add one before or after, or several do do some extra drawing. > to a Lisp function anywhere in Emacs, the question is what thats > function will be able to do to be useful. Essentially it would be like layered rendering. Imagine Gimp layers. Since each hook is drawing it's own stuff it would be like a layer. For example, if Emacs exposed some graphics stuff like say: draw-this, fill-that, and if drawing layered, like in post-render, that wouldn't collide with overlays and other stuff, one could draw over images etc. Similarly a pre-render could put some graphics and images that appear as a background below normal buffer text. > If the called Lisp can do > anything it wants, then how can it be useful without knowing a whole > lot about the window layout, and what was just now, or will be in a > moment, drawn on it, and in which parts? Each hook woul have it's own associated buffer, which could be same as current buffer or different one (say an temporary with an image in it). Redisplay engine can then just do whatever it does now to figure out that buffer so no changes to redisplay engine. Yes, it would draw in same pixel coordinates of the window it is drawing on. The only hard part would be to figure out how to trigger redisplay engine when some of buffers with associated hooks changes (I think, but I am not knowledgable enough about implementation details here). >> Prerender callback could be any user lisp function called >> that do anything it wants, say draw something on the screen as it owned >> window itself. Than render engine would it's ordinary rendering drawing >> just as it does now, pretending that there was nothing already drawn, so >> it would mean no change at all to current c code for rendering. > > So how do we prevent the display engine from blissfully drawing over > what the pre-render draws? You don't! It is exactly my point to redraw over stuff. Render should re-draw over what pre-render has drawn etc. That way, if a pre-render hook, draws say a buffer with an image in it, then ordinary buffer can draw it's text over it and image would appear as a background in final view. >> Similarly one call a post-render callback and draw over the already >> rendered text so user could draw whatever on top of already draw >> onverlas and what not. > > How will the post-render know where it can and where it cannot draw? > Or even where to draw, for that matter (assuming you want to do > something more useful than just put the same pixels in the same pixel > coordinates)? Actually sometimes, you do want to just put pixels in same pixel coordinates :-). But anyway, one could draw some lines below/above text in buffers, rectangles, and so on. Info about where and what to draw comes well from user code. User's elisp can figure out where and what to draw by examining the buffer and window with usual elisp we have now? > For example, if the window scrolls, wouldn't you want > the graphics drawn by these pre/post-renderers to move on display as > well, at least sometimes? If you do, how can you do that without > knowing some details about the scroll? Of course. Wouldn't came out automatically, by redisplay engine as it already is? >> It is just how z-buffer works and it would mean z order from pre-render, >> normal render (as it is now) and post render as implicit z-depths. > > AFIU, z-buffer doesn't care to obscure what's displayed below. is > this what you have in mind: obscuring the "normal" display with some > graphics? No I didn't, I had in mind to redraw stuff, so user can draw below or above whatever Emacs normally draws. Yeah sure if user chooses to draw two different text buffers on top of each other it would be a mess, but I don't think that is an issue because, normally, probably nobody want's to draw to text files on top of each other.