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 16:29:19 +0300 Message-ID: <835zdhxftc.fsf@gnu.org> 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> <87d07qdrkd.fsf@randomsample> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="105876"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 30 15:33:26 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 1jU9Jc-000RN4-MC for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 15:33:24 +0200 Original-Received: from localhost ([::1]:60422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jU9Jb-0006k2-NB for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 09:33:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46994) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jU9G2-0004Oo-0f for emacs-devel@gnu.org; Thu, 30 Apr 2020 09:32:17 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48703) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jU9G1-00031g-4Q; Thu, 30 Apr 2020 09:29:41 -0400 Original-Received: from [176.228.60.248] (port=4175 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jU9Ft-0004Ws-TC; Thu, 30 Apr 2020 09:29:39 -0400 In-Reply-To: <87d07qdrkd.fsf@randomsample> (message from David Engster on Wed, 29 Apr 2020 21:23:30 +0200) 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:248230 Archived-At: > From: David Engster > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Wed, 29 Apr 2020 21:23:30 +0200 > > > AFAIU, Meld seems to draw the graphics _between_ windows, and only > > highlights the source lines with background colors. I think we can do > > that if we use an extra window in-between the two being compared, and > > put images in that extra window to show the graphical description of > > the changes between the two versions. > > I actually tried exactly that, many years ago. I dimly remember that > handling the coordinates was pretty complicated and it was slow. Like, > orders of magnitude too slow, even with the simplest and fastest image > types. There was no way you would ever be able to scroll text and update > the diff visualization alongside it. It was just a flickery mess. It > would of course be possible to visualize the diff in an idle timer and > not during scrolling, but that is exactly what I mean above with "not > really satisfactory", so I gave up. Hmm... yes, I see your point. We'd need to find a way of somehow synchronizing the windows, which is not very easy (witness follow-mode). > > 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? > > When I played around with it, I thought a first iteration could be to > simply expose the basic Cairo API to ELisp, which is essentially drawing > lines/arcs/rectangles and filling. I thought that maybe it would be > possible that one could handle this like a graphical transparent > overlay, but I'm afraid I'm way out of my depth here. I have no idea how > one would handle scrolling, for instance. Right, the main problem is not how to draw, but how to tell the display engine where's the drawing on the screen, and when to redraw it.