emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Mac port


From: Eli Zaretskii
Subject: Re: Emacs Mac port
Date: Mon, 15 Apr 2013 13:57:14 +0300

> Date: Mon, 15 Apr 2013 18:48:29 +0900
> From: YAMAMOTO Mitsuharu <address@hidden>
> Cc: address@hidden
> 
> > I'm still interested to know why this cannot be done entirely in the
> > display back-end.
> 
> 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?

> (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?  Does
the expose event on the Mac interrupt sleep-for?

> >> The reason is simple: the expose handler should recover the
> >> contents of the previous redisplay with respect to the requested
> >> rectangle.
> 
> > And yet we don't see the result on any other platform.
> 
> 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.

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?

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]