Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 15 Apr 2013 13:57:14 +0300, Eli Zaretskii <address@hidden> said:

>> I'm using the "expose" handler for recovering the display contents
>> through invalidation, because that is really what it is for.
>> 
>> 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é"
>> (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))
>> 
>> 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
                        address@hidden