From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Can we go GTK-only? Date: Sun, 30 Oct 2016 19:57:31 -0400 Message-ID: References: <24db2975-17ca-ad01-20c8-df12071fa89a@dancol.org> <4615E73A-19E2-4B79-9889-D3FA686DDDE6@raeburn.org> <11E61536-1345-4B81-999D-2E17F8B14C62@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477871941 2716 195.159.176.226 (30 Oct 2016 23:59:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 30 Oct 2016 23:59:01 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: Ken Raeburn , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 31 00:58:58 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 1c0zzf-00053h-OR for ged-emacs-devel@m.gmane.org; Mon, 31 Oct 2016 00:58:27 +0100 Original-Received: from localhost ([::1]:60603 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0zzi-0002v4-DZ for ged-emacs-devel@m.gmane.org; Sun, 30 Oct 2016 19:58:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0zyt-0002sr-DU for emacs-devel@gnu.org; Sun, 30 Oct 2016 19:57:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c0zyo-0003qh-Jz for emacs-devel@gnu.org; Sun, 30 Oct 2016 19:57:39 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:1868) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c0zyo-0003qV-Di for emacs-devel@gnu.org; Sun, 30 Oct 2016 19:57:34 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DdBQALW9BX/+953mhdGwEBAQMBAQGDLQEBAQEBHoRNhVCvdoIDhhYEAgKBaTsSAQIBAQEBAQEBXieEYgEBAwFWIwULCw4mEhQYDSSIVQi8VQELJYp9ihwBBJlZkSuHYoYLhnOJWCUIJ4RsIINcKoIEAQEB X-IPAS-Result: A0DdBQALW9BX/+953mhdGwEBAQMBAQGDLQEBAQEBHoRNhVCvdoIDhhYEAgKBaTsSAQIBAQEBAQEBXieEYgEBAwFWIwULCw4mEhQYDSSIVQi8VQELJYp9ihwBBJlZkSuHYoYLhnOJWCUIJ4RsIINcKoIEAQEB X-IronPort-AV: E=Sophos;i="5.30,296,1470715200"; d="scan'208";a="277640223" Original-Received: from 104-222-121-239.cpe.teksavvy.com (HELO fmsmemgm.homelinux.net) ([104.222.121.239]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Oct 2016 19:57:33 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 034B5AE0CB; Sun, 30 Oct 2016 19:57:31 -0400 (EDT) In-Reply-To: <11E61536-1345-4B81-999D-2E17F8B14C62@dancol.org> (Daniel Colascione's message of "Sun, 30 Oct 2016 15:49:02 -0700") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:209002 Archived-At: > But this scheme won't really eliminate the coupling between redisplay and > lisp though, since the former calls into the latter. The redisplay thread > has to block waiting on lisp anyway. Indeed. Moving redisplay to a separate thread would be neat, but it'd take a much more significant amount of work, I think. > 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, so either we need the two threads to belong to the same process and we temporarily use locking (but this locking is not used when responding to expose events, it's only used to update the current matrices), or we need a 3rd copy. Stefan