From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Can we go GTK-only? Date: Mon, 31 Oct 2016 05:37:57 +0200 Message-ID: <83k2cpp4ru.fsf@gnu.org> References: <24db2975-17ca-ad01-20c8-df12071fa89a@dancol.org> <4615E73A-19E2-4B79-9889-D3FA686DDDE6@raeburn.org> <11E61536-1345-4B81-999D-2E17F8B14C62@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477885101 12097 195.159.176.226 (31 Oct 2016 03:38:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 31 Oct 2016 03:38:21 +0000 (UTC) Cc: dancol@dancol.org, raeburn@raeburn.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 31 04:38:17 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c13Q1-00081Y-Jm for ged-emacs-devel@m.gmane.org; Mon, 31 Oct 2016 04:37:53 +0100 Original-Received: from localhost ([::1]:32984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c13Q4-0001Tb-BP for ged-emacs-devel@m.gmane.org; Sun, 30 Oct 2016 23:37:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51791) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c13Px-0001TV-UA for emacs-devel@gnu.org; Sun, 30 Oct 2016 23:37:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c13Pt-0001uj-Vd for emacs-devel@gnu.org; Sun, 30 Oct 2016 23:37:49 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c13Pt-0001ue-SE; Sun, 30 Oct 2016 23:37:45 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2841 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c13Ps-0008FL-LC; Sun, 30 Oct 2016 23:37:45 -0400 In-reply-to: (message from Stefan Monnier on Sun, 30 Oct 2016 19:57:31 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209006 Archived-At: > From: Stefan Monnier > Date: Sun, 30 Oct 2016 19:57:31 -0400 > Cc: Ken Raeburn , emacs-devel@gnu.org > > > The key insight there is that we shouldn't have redisplay *lock* the display > > matrix and render it. The lisp universe should send a *copy* of the matrix > > set, then go about its business. > > Good, point we can decouple the two a bit more this way. Actually, we > already have this copy since we have 2 sets of matrices. So we just > need to say that the "current matrix" belongs to the GUI thread/process, > while the "desired matrix" belongs to the redisplay. And the "send > a copy" is done by comparing the two, so only the part that changed is > sent (and so the GUI thread gets to know which part needs to be redrawn). > > Of course, comparing the two sets of matrices requires access to both, What's more, some redisplay optimizations use the current matrices without constructing the desired ones. But since the matrices are not exposed to Lisp, I don't understand why you think there's any problem to be solved here.