Re: Emacs Mac port

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Tue, 16 Apr 2013 09:49:17 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> 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?

The problem due to anti-aliasing happens if you round the corners
multiple times.  Exposing the bottom part can make sure that the
corners are freshly redrawn and rounding is always done exactly once.

That shows a typical reason why recent toolkits treat the "expose"
handler as the primary drawing method.  By freshly redrawing
invalidated area in a rear-to-front way, it can provide some fancy
appearances such as overlapped/translucent widgets in a correct way.

(Another problem with drawing outside the "expose" handler can be
observed with the NS port on Mac OS X 10.6 and earlier: the resize
handle at the right bottom corner gets overwritten.)

>> 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"?

Some implementations of Xservers.  According to the manual, -bs option
seems to turn off the backing store support.

>> 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.

I'm just saying that the current "expose" handler has a bug in the
platform-independent part with respect to cursor drawing.

It would be true that the "expose" hander is used to be considered
subsidiary drawing method and used in a limited situation
traditionally, but that is no longer true.

>> 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?

No.  Redisplay involves Lisp evaluation, which is prohibited in the
context of read_socket_hook where the "expose" handler is called.

>> 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.

Mac does have "backing store".  I meant Xserver implementation without
"backing store".  I vaguely remember Xvnc didn't have one and issued
"expose" events every time a window is uncovered, but I'm not sure
about the recent situation of Xservers.

				      YAMAMOTO Mituharu
				mituharu@math.s.chiba-u.ac.jp