Re: Emacs Mac port

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 16 Apr 2013 09:17:33 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 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.