From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs Mac port Date: Tue, 16 Apr 2013 09:49:17 +0300 Message-ID: <838v4j55si.fsf@gnu.org> References: <83ip3p72mz.fsf@gnu.org> <83d2tw73h7.fsf@gnu.org> <8361zo6um1.fsf@gnu.org> <8338us6oz9.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1366094950 17483 80.91.229.3 (16 Apr 2013 06:49:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Apr 2013 06:49:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 16 08:49:14 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 1URzha-0002mE-8K for ged-emacs-devel@m.gmane.org; Tue, 16 Apr 2013 08:49:14 +0200 Original-Received: from localhost ([::1]:57874 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URzhZ-0005I2-Tv for ged-emacs-devel@m.gmane.org; Tue, 16 Apr 2013 02:49:13 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URzhW-0005Hl-L6 for emacs-devel@gnu.org; Tue, 16 Apr 2013 02:49:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URzhU-00008i-46 for emacs-devel@gnu.org; Tue, 16 Apr 2013 02:49:10 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:43353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URzhT-00008J-MJ for emacs-devel@gnu.org; Tue, 16 Apr 2013 02:49:08 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MLC009005DUFV00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 16 Apr 2013 09:49:05 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MLC008A95LTUO70@a-mtaout22.012.net.il>; Tue, 16 Apr 2013 09:49:05 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:158939 Archived-At: > Date: Tue, 16 Apr 2013 09:17:33 +0900 > From: YAMAMOTO Mitsuharu > Cc: emacs-devel@gnu.org > > 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. So how delegating this to the time expose event is handled overcomes that problem? IOW, what code handles the rounding in response to the expose event, and why can't you call or trigger the same code from update_end_hook? > 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.) You can laugh, if you want, but I still think it's abuse, and won't be convinced by being laughed at. > 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. Which window systems we support don't use "backing store"? > > 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. We have no control on how other software is written. We only have control on how Emacs is designed and implemented. Look, I'm wearing here the hat of an Emacs maintainer who is concerned about the maintainability of the Emacs display code in the long run. Witness the amount of discussions lately that involve flags and options for which no one remembers their purpose or intended use any longer. Witness the amount of changes done recently on the trunk to rightfully remove ancient crud, which sometimes later turns out to be needed, for reasons no one at the time cared to document clearly enough. You are suggesting to add one more such flag, don't you see? Who will remember a few years from now why it was needed, which problem on what platform(s) it fixed, and how that problem could be reproduced? I'll tell you: NO ONE WILL REMEMBER!! So arguments that describe how other software works are of no value here, because the size and activity of the maintenance teams of these other projects are most probably very different from the "team" that maintains the Emacs display code. IOW, by telling time and again how these techniques are used elsewhere, you are wasting your time. > > 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. Sorry, you lost me here. An expose event just triggers another redisplay, so what's that "unchanged until the next redisplay" about? > >> 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. If there are no such systems except the Mac, then in practice this still is a problem specific to that single platform.