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: Tue, 16 Apr 2013 09:17:33 +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> 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 1366071463 6945 80.91.229.3 (16 Apr 2013 00:17:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Apr 2013 00:17:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 16 02:17:47 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 1URtal-0004DJ-IY for ged-emacs-devel@m.gmane.org; Tue, 16 Apr 2013 02:17:47 +0200 Original-Received: from localhost ([::1]:41387 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URtal-0004D9-4e for ged-emacs-devel@m.gmane.org; Mon, 15 Apr 2013 20:17:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:32792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URtah-0004D2-Nf for emacs-devel@gnu.org; Mon, 15 Apr 2013 20:17:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URtag-0005hW-2J for emacs-devel@gnu.org; Mon, 15 Apr 2013 20:17:43 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:53240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URtad-0005gg-6B; Mon, 15 Apr 2013 20:17:39 -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 858C6C055D; Tue, 16 Apr 2013 09:17:33 +0900 (JST) In-Reply-To: <8338us6oz9.fsf@gnu.org> 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:158937 Archived-At: >>>>> On Mon, 15 Apr 2013 13:57:14 +0300, Eli Zaretskii said: >> I'm using the "expose" handler for recovering the display contents >> through invalidation, because that is really what it is for. >>=20 >> On Mac, the "expose" handler is called in many situations than you >> might expect including outside the control of application code: >> e.g., creating a snapshot of the window image for icons or "Expos=E9" >> (http://support.apple.com/kb/HT2503). I'm not sure about other >> platforms/toolkits, but I wouldn't be surprised if similar things >> happen there for providing some fancy features. Nowadays, drawing >> outside the "expose" handler is exceptional and subject to several >> restrictions. > Sorry, I don't understand. I was asking why the code that makes the > corners of the window round cannot be run directly from the GUI > drawing code of the Mac display back-end, e.g., from the update_end > method. Why does it _have_ to be run from the expose handler? I actually tried to round the bottom corners by calling some undocumented API from update_end_hook in the very first trial. Repeated rounding made the corner shaper because of anti-aliasing there. Again, invalidating an area to let the "expose" handler draw afterwards is a very standard, primary, canonical, and sometimes only way of drawing nowadays. (If you call it is an abuse or trick, you'll be laughed.) Application frameworks also treat it as primary, so the other unusual drawing methods (i.e., outside the "expose" handler) are not the primary target, and some newer features are not available if you use "nonstandard" ways of drawing. Bottom corner rounding is just an example of such cases. >> (progn (let ((cursor-in-echo-area t)) (message "foo") (sit-for 0)) >> (sleep-for 10)) >>=20 >> If the "expose" event happen for the echo area during the execution >> of sleep-for, would the cursor be correctly recovered? > I cannot make it produce an incorrect cursor, but maybe I don't > generate the expose event as you intended. How did you do it? If you use a window system implementation that uses "backing store" to avoid frequent "expose", then it is difficult to produce the "expose" event intentionally by uncovering the window. > Does the expose event on the Mac interrupt sleep-for? sleep-for is usually blocking at `select' (or its emulation) call, which is supposed to return when some window system event (such as C-g or expose) becomes available. The "expose" handler is called there. >> You don't agree the principle for the "expose" handler above (i.e., >> it should recover the contents of the previous redisplay)? Then >> what is your expected behavior of the "expose" handler? > I don't like the expose event being used for this purpose in the > first place. Platform-specific pixel-level drawing shouldn't IMO be > exposed to the device-independent portions of the display engine. You can't tell how "expose" events are used from Application frameworks or toolkits. Whether you like it or not, contemporary ones (such as GTK+ and Cocoa) treat the "expose" handler as the primary drawing method and use it accordingly, regardless of the internal use from the application code. > And second, I don't think I understand what needs to be recovered > except what the glyph matrix describes. The redisplay that happens > in response to the expose event needs to know where to draw the > cursor and how to draw it _at_the_moment_of_redisplay_; why is it > important where the cursor was during previous redisplay cycle, if > it is no longer there and shouldn't be there? What's displayed is assumed to be unchanged until the next redisplay in the first place, even if several "expose" events happen in between. Otherwise, you can't use several optimizations in redisplay that reuse the existing contents. >> I don't insist my patch is correct. But I'd say the current >> behavior is wrong and the fix should be done in the >> platform-independent part rather than in the code for a particular >> platform where the problem happens to easily emerge. > I asked you to describe a series of events that could reproduce such > a problem, and your description was about a Mac-specific feature. > If this is a platform-independent problem, there should be a way of > reproducing it on other platforms as well. As I said above, you'll need a window system implementation that doesn't use "backing store" in order to reproduce the phenomena reliably. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp