emacs-devel
[Top][All Lists]
Advanced

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

Re: redisplay and expose_frame


From: YAMAMOTO Mitsuharu
Subject: Re: redisplay and expose_frame
Date: Wed, 25 Jul 2018 18:33:35 +0900
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/25.3 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

On Wed, 25 Jul 2018 05:42:20 +0900,
Alan Third wrote:

> > > The background here is that I’m working on splitting the NS port’s GUI
> > > code into its own thread, and while working on that I noticed that
> > > Apple have deprecated the method we use to draw, so I thought that
> > > since I’m working with the code anyway, I may as well try to
> > > ‘modernise’ it.
> > 
> > A related thread can be found around
> > http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg00821.html .
> 
> That’s interesting, and confirms some of what I’d thought. I take it
> nothing ever came of it, though?

AFAIK, nothing public.  It's been difficult for me to tell how
important the "expose" handler is to developers on other platforms
(e.g., the thread starting from
http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00392.html).

> > Mojave, the next version of macOS, already prohibits drawing outside
> > "drawRect:" by default if the executable was linked on that version.
> > An attempt to draw outside "drawRect:" triggers invalidation of all
> > the contents instead, and it is completely redrawn (even for a single
> > cursor movement) via "drawRect:" at the next cycle of the event loop.
> > This is kinda usable for small frames on recent machines, but not
> > efficient of course, especially for full screen frames.
> 
> This doesn’t sound good, and I wonder if bug#31904 is related,
> although it doesn’t sound like it should be.
> 
> Is the Mac port affected by this, or does it avoid this Cocoa stuff?

There were several problems, but non-performance issues are mostly
solved in the "work" branch of the Mac port repository
(https://bitbucket.org/mituharu/emacs-mac).  It now works as in a
"kinda usable" way with the whole invalidation mentioned above.

> I suppose, to avoid changes in redisplay code, I could make the NS
> drawing functions detect whether they are running in the main thread
> (or perhaps they can just ask whether they’re able to draw or not),
> and if they’re not then invalidate the relevant rectangle, and if they
> are then do the actual drawing task.
> 
> Then call display for each frame to force an expose ‘event’ at the end
> of redisplay.

Back in early 2007, I privately experimented something like that
(without threading) with "modern Carbon" (HIWindow), where drawing
outside the "expose" callback was deprecated like the current
situation for Cocoa.  I could actually find a platform-independent bug
that was otherwise difficult to find/reproduce
(http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg01279.html)
by this experiment, but the overall performance was not quite
satisfactory then.  So, I was surprised to see that (the "work" branch
of) the Mac port with the whole invalidation was "kinda usable" on
recent machines running Mojave.

                                     YAMAMOTO Mitsuharu
                                address@hidden




reply via email to

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