emacs-devel
[Top][All Lists]
Advanced

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

Re: redisplay and expose_frame


From: Alan Third
Subject: Re: redisplay and expose_frame
Date: Sat, 4 Aug 2018 17:19:13 +0100
User-agent: Mutt/1.10.0 (2018-05-17)

On Wed, Jul 25, 2018 at 06:33:35PM +0900, YAMAMOTO Mitsuharu wrote:
> > 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.

I’ve implemented this (without threading) and, like you say, the
performance is pretty good. I can’t actually see any difference on my
Mac.

Unfortunately GNUstep is not as happy. It runs MUCH slower, to the
extent that scrolling really doesn’t work at all. Turning off the
menubar improves things, but not enough.

Mind you, looking at the scrolling code again now, I think it’s
forcing essentially the whole window to be redrawn anyway, so that
won’t help.
-- 
Alan Third



reply via email to

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