From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs canvas support Date: Thu, 30 Apr 2020 21:42:49 +0300 Message-ID: <83pnbox1au.fsf@gnu.org> References: <83o8raziis.fsf@gnu.org> <877dxy1smz.fsf@yahoo.com> <87o8rae0ao.fsf@randomsample> <83lfmexmfp.fsf@gnu.org> <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> <831ro5xezy.fsf@gnu.org> <83tv10x4st.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="24134"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, 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 20:44:33 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 1jUEAi-0006AM-Ou for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 20:44:32 +0200 Original-Received: from localhost ([::1]:59980 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUEAh-0005KR-89 for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 14:44:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40168) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUE9L-0003Kf-Qb for emacs-devel@gnu.org; Thu, 30 Apr 2020 14:43:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55653) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUE9L-0001St-Hr; Thu, 30 Apr 2020 14:43:07 -0400 Original-Received: from [176.228.60.248] (port=3749 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jUE9J-00026N-Oi; Thu, 30 Apr 2020 14:43:06 -0400 In-Reply-To: (message from Stefan Monnier on Thu, 30 Apr 2020 14:22:02 -0400) 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:248258 Archived-At: > From: Stefan Monnier > Cc: tomas@tuxteam.de, emacs-devel@gnu.org > Date: Thu, 30 Apr 2020 14:22:02 -0400 > > > I don't think I understand how this would fit into the current > > redisplay framework. > > I think it should basically not require touching xdisp.c. > It should work at the level of `update_window` only. I _am_ talking about update_frame and update_window. They have their own ideas about which parts of the screen need to be updated and which don't, and how they should be updated (whether by scrolling or by deletion and insertion or by overwriting). Those ideas are based on the assumption that they know what is currently on the glass. That knowledge comes from the glyph matrices. If the canvasses are drawn independently of the glyph matrices, then update_window will make wrong decisions, and the result will be a royal mess on the screen. Maybe I'm missing something, but you didn't actually explain on any level of detail how do you propose to "compose" the "normal" display with the canvasses. How about if you try to describe your ideas in two simple use cases: (1) when a canvas that was on display, overlaying some text, is deleted (and nothing else is changed); and (2) when update_window decides to scroll some part of a window which has a canvas partially overlaying the text in the part to be scrolled?