From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Cairo branch. Date: Thu, 12 Feb 2015 11:18:41 -0500 Message-ID: References: <54DB723D.5030303@swipnet.se> <54DCC037.7030202@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423757942 19005 80.91.229.3 (12 Feb 2015 16:19:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Feb 2015 16:19:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Jan D." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 12 17:18:53 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YLwTc-0007O5-GW for ged-emacs-devel@m.gmane.org; Thu, 12 Feb 2015 17:18:52 +0100 Original-Received: from localhost ([::1]:50955 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLwTb-0006dw-LL for ged-emacs-devel@m.gmane.org; Thu, 12 Feb 2015 11:18:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLwTX-0006dq-Si for emacs-devel@gnu.org; Thu, 12 Feb 2015 11:18:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLwTT-0007sW-Sf for emacs-devel@gnu.org; Thu, 12 Feb 2015 11:18:47 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:48536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLwTT-0007sP-L1 for emacs-devel@gnu.org; Thu, 12 Feb 2015 11:18:43 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t1CGIfto017653; Thu, 12 Feb 2015 11:18:41 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id DAFB7A76; Thu, 12 Feb 2015 11:18:41 -0500 (EST) In-Reply-To: <54DCC037.7030202@swipnet.se> (Jan D.'s message of "Thu, 12 Feb 2015 16:01:11 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5215=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5215> : inlines <2144> : streams <1389079> : uri <1853412> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182960 Archived-At: > YAMAMOTO Mitsuharu made the patch to demonstrate printing, so that is new > (see x-print-frames-dialog or the Printing section in xfns.c). Oh, yes, I had forgotten about that one. > Otherwise it is just a step to keep up with the times, i.e. server side (as > in X11 server) rendering is going away as it seems. So Emacs must at some > point develop client side (cairo) rendering. So, IIUC the effect is to change the underlying code used to *draw* the actual windows (but not the widgets like menubar, scrollbars, ...). Does it affect font selection? > It could form a basis for porting to other window systems like Wayland, that > has no rendering of its own, but relies on cairo. That takes more effort, > the cairo branch is X only. Note that porting to Wayland isn't as simple as > switching rendering, the whole event handling must be implemented. OK. > I think using cairo and going double buffer in Emacs is easier than making > X double buffered. The main obstacle to double buffering is the way Emacs > does redraw, i.e. not in the GUI loop, but outside it. This is tricky to > change, as there are lots of flags in the redraw code that gets set and > reset at various points. Figuring all that stuff out is not easy. I don't understand this part of the code nearly enough to say something intelligent, but based on my work on the pre-redisplay-function feature (trying to optimize the set of windows that need to be redrawn), I think I understand a bit of what you mean. Stefan