From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Emacs Mac port Date: Fri, 19 Apr 2013 12:58:17 +0900 Organization: Faculty of Science, Chiba University Message-ID: 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 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1366343907 2975 80.91.229.3 (19 Apr 2013 03:58:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Apr 2013 03:58:27 +0000 (UTC) Cc: Eli Zaretskii , Stefan Monnier , "emacs-devel@gnu.org" To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 19 05:58:30 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 1UT2Sy-0003MZ-LV for ged-emacs-devel@m.gmane.org; Fri, 19 Apr 2013 05:58:28 +0200 Original-Received: from localhost ([::1]:38830 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UT2Sy-0003hh-CC for ged-emacs-devel@m.gmane.org; Thu, 18 Apr 2013 23:58:28 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UT2Su-0003hY-HO for emacs-devel@gnu.org; Thu, 18 Apr 2013 23:58:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UT2St-0003U4-Ce for emacs-devel@gnu.org; Thu, 18 Apr 2013 23:58:24 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:50204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UT2Sr-0003Tf-7X; Thu, 18 Apr 2013 23:58:21 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 66359C0561; Fri, 19 Apr 2013 12:58:17 +0900 (JST) In-Reply-To: <4AE1DFD7-9117-4F1C-B393-28EC39597850@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 133.82.132.2 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:159011 Archived-At: >>>>> On Wed, 17 Apr 2013 08:36:25 +0200, Jan Dj=E4rv = said: >>> 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. > This is not just for cairo. Gtk+ double buffers anything drawn with > Gtk in the expose handler. For example, menus and toolbar in a Gtk > Emacs are double buffered. According to the document (*), (standard) drawing seems to be eventually done via cairo on GTK+ 3. *: https://developer.gnome.org/gtk3/3.0/gtk-migrating-2-to-3.html#id1526151 In GTK+ 3, the GDK drawing API (which closely mimics the X drawing API, which is itself modeled after PostScript) has been removed. All drawing in GTK+ 3 is done via cairo. > If moving things to the expose handler is considered, one must take > into account non-Gtk X11 builds. X11 does not have a mechanism for > invalidating regions 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). Right. Probably invalidated region management at the application level is also meaningful/necessary for Cocoa, because scrolling or pixel copying in AppKit, which will be used in x_scroll_run, does not take account of the invalidated region managed by the framework. > 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 would be visible to the user at some point > in the future, not when the Lisp code is done. Unless some > synchronization is added between Lisp code and the expose handler. The expose handler will be called when Emacs tries to read some input from the window system. If display is not updated for a long time because of deferring, that means C-g is not handled for a long time either. If immediate update after redisplay is really necessary for some cases, gdk_window_process_all_updates or something could be used (after making sure that the current matrix is ready and clearing f->garbaged). YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp