From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?Jan_Dj=C3=A4rv?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs Mac port Date: Wed, 17 Apr 2013 08:36:25 +0200 Message-ID: <4AE1DFD7-9117-4F1C-B393-28EC39597850@swipnet.se> References: <83ip3p72mz.fsf@gnu.org> <83d2tw73h7.fsf@gnu.org> <8361zo6um1.fsf@gnu.org> <8338us6oz9.fsf@gnu.org> <838v4j55si.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1366180599 30805 80.91.229.3 (17 Apr 2013 06:36:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Apr 2013 06:36:39 +0000 (UTC) Cc: Eli Zaretskii , Stefan Monnier , "emacs-devel@gnu.org" To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 17 08:36:43 2013 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 1USLz1-0005KG-4P for ged-emacs-devel@m.gmane.org; Wed, 17 Apr 2013 08:36:43 +0200 Original-Received: from localhost ([::1]:52431 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USLz0-00032K-LJ for ged-emacs-devel@m.gmane.org; Wed, 17 Apr 2013 02:36:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46917) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USLyv-000327-1e for emacs-devel@gnu.org; Wed, 17 Apr 2013 02:36:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USLyu-00079U-0J for emacs-devel@gnu.org; Wed, 17 Apr 2013 02:36:36 -0400 Original-Received: from mailout.melmac.se ([62.20.26.67]:59057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USLyt-000780-Kc for emacs-devel@gnu.org; Wed, 17 Apr 2013 02:36:35 -0400 Original-Received: from mail01.melmac.se (mail01.melmac.se [62.20.26.80]) by mailout.melmac.se (Postfix) with ESMTP id 0CA79C565 for ; Wed, 17 Apr 2013 08:36:33 +0200 (CEST) Original-Received: (qmail 116 invoked by uid 89); 17 Apr 2013 06:35:49 -0000 Original-Received: from h-46-59-42-18.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.18) by mail01.melmac.se with ESMTPA; 17 Apr 2013 06:35:49 -0000 Original-Received: from [172.16.2.149] (gw01.ismobile.com [176.57.193.190]) by coolsville.localdomain (Postfix) with ESMTPSA id 8545C7FA058; Wed, 17 Apr 2013 08:36:32 +0200 (CEST) In-Reply-To: X-Mailer: iPhone Mail (10B329) X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 62.20.26.67 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:158976 Archived-At: Hello. 17 apr 2013 kl. 07:46 skrev YAMAMOTO Mitsuharu : >>>>>> On Wed, 17 Apr 2013 07:08:25 +0200, Jan Dj=C3=A4rv said: >=20 >> 17 apr 2013 kl. 01:52 skrev YAMAMOTO Mitsuharu : >>>=20 >>> My proof-of-concept cairo port was primarily intended for the printing >>> support, not for screen drawing (though it does both). >>>=20 >>> http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00390.html >>>=20 >>> Screen drawing in the cairo port is not so efficient for several >>> reasons. To make it more efficient, one would need some modest >>> modifications to the current drawing model in Emacs. >>>=20 >>> 1. Don't draw during redisplay, but mark the updated area dirty so >>> the upcoming exposure event can trigger the actual redraw for the >>> area to be updated. >>> 2. Restrict the actual drawings to those in response to exposure >>> events. This is the standard way in GTK+ and Cocoa. That would >>> make double-buffering straightforward in GTK+ builds. >=20 >> Double buffering in the Gtk+ is not turned off because of the expose >> handler, but because Gtk+ can not double buffer text/images not >> drawn with Gtk/Gdk primitives, and Emacs uses X primitives. So >> changing the way expose handler works does absolutely nothing to >> make Gtk+ double buffering easier. >=20 > That would be correct in itself. But my description above is in the > context of cairo. The cairo context passed via the expose handler is > automatically double-buffered. >=20 This is not just for cairo. Gtk+ double buffers anything drawn with Gtk in t= he expose handler. For example, menus and toolbar in a Gtk Emacs are double b= uffered. If moving things to the expose handler is considered, one must take into acc= ount non-Gtk X11 builds. X11 does not have a mechanism for invalidating regi= ons for the purpose of generating an expose event. Gtk+ generates syntetic (= internal) expose events. I guess we could do the same, but it is work to be= done by someone(tm). I also suspect the synchronous nature of Elisp would make this complicated. = For example, if Lisp code adds text or image to a buffer, the text or image w= ould be visible to the user at some point in the future, not when the Lisp c= ode is done. Unless some synchronization is added between Lisp code and the e= xpose handler.=20 Jan D.=20