Change to NS drawing routines

Change to NS drawing routines

[Alan Third]

The next version of macOS deprecates the method we use in the NS port
to draw to the screen, specifically marking an NSView as ‘focused’ and
then drawing to it. The ‘modern’ way is to only draw from within the
‘drawRect:’ method where ‘focusing’ is already done for you. There is
some previous discussion here:

https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00799.html

I’ve created a new branch called scratch/ns-drawing which only draws
from within drawRect by marking areas that are to be drawn as ‘dirty’
and then, at the end of redisplay, forcing an update, which uses
drawRect and expose_frame to redraw the relevant bits of the frame.

I believe this is a somewhat controversial approach.

My experience so far is that performance is not noticeably slower than
master, however if someone with a slower Mac could try it that would
be helpful. 
-- 
Alan Third

Re: Change to NS drawing routines

[Charles A. Roelli]

> Date: Sat, 11 Aug 2018 15:06:20 +0100
> From: Alan Third <alan@idiocy.org>
> 
> The next version of macOS deprecates the method we use in the NS port
> to draw to the screen, specifically marking an NSView as ‘focused’ and
> then drawing to it. The ‘modern’ way is to only draw from within the
> ‘drawRect:’ method where ‘focusing’ is already done for you. There is
> some previous discussion here:
> 
> https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00799.html
> 
> I’ve created a new branch called scratch/ns-drawing which only draws
> from within drawRect by marking areas that are to be drawn as ‘dirty’
> and then, at the end of redisplay, forcing an update, which uses
> drawRect and expose_frame to redraw the relevant bits of the frame.
> 
> I believe this is a somewhat controversial approach.

Why's that?

> My experience so far is that performance is not noticeably slower than
> master, however if someone with a slower Mac could try it that would
> be helpful.

I don't notice a speed difference compared to master on my slow box
running macOS 10.6.  Do we have any benchmarks that we could use to
check?

Re: Change to NS drawing routines

[Nick Helm]

Alan Third <alan@idiocy.org> writes:

> if someone with a slower Mac could try it that would
> be helpful

I tried it on the oldest machine I have here (a 2010 mini) and I
couldn't tell the difference between the branch and master.

I can run specific tests if you have something in mind.

Re: Change to NS drawing routines

[Van L]

> My experience so far is that performance is not noticeably slower than
> master, however if someone with a slower Mac could try it that would
> be helpful. 

On macos 10.11, it seems faster than 26.1 emacs.

Thank you.

Re: Change to NS drawing routines

[Alan Third]

On Sun, Aug 12, 2018 at 12:47:17PM +0200, Charles A. Roelli wrote:
> > Date: Sat, 11 Aug 2018 15:06:20 +0100
> > From: Alan Third <alan@idiocy.org>
> > 
> > The next version of macOS deprecates the method we use in the NS port
> > to draw to the screen, specifically marking an NSView as ‘focused’ and
> > then drawing to it. The ‘modern’ way is to only draw from within the
> > ‘drawRect:’ method where ‘focusing’ is already done for you. There is
> > some previous discussion here:
> > 
> > https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00799.html
> > 
> > I’ve created a new branch called scratch/ns-drawing which only draws
> > from within drawRect by marking areas that are to be drawn as ‘dirty’
> > and then, at the end of redisplay, forcing an update, which uses
> > drawRect and expose_frame to redraw the relevant bits of the frame.
> > 
> > I believe this is a somewhat controversial approach.
> 
> Why's that?

Going through the previous email discussions, linked in the thread
above, Eli made it clear that he sees using the expose functions to
draw, when it’s not an expose event, as being incorrect.

i.e. this:

> > 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.)
> 
> You can laugh, if you want, but I still think it's abuse, and won't
> be convinced by being laughed at.

from http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00435.html

I can understand the argument to an extent, but I don’t have another
solution.

> > My experience so far is that performance is not noticeably slower than
> > master, however if someone with a slower Mac could try it that would
> > be helpful.
> 
> I don't notice a speed difference compared to master on my slow box
> running macOS 10.6.  Do we have any benchmarks that we could use to
> check?

Unfortunately I’m not aware of any. I’m tempted to say that if there
is no clear performance penalty, then it’s not a problem.

Thanks everyone for testing this.
-- 
Alan Third

Re: Change to NS drawing routines

[Eli Zaretskii]

> Date: Mon, 13 Aug 2018 19:46:59 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: emacs-devel@gnu.org
> 
> Going through the previous email discussions, linked in the thread
> above, Eli made it clear that he sees using the expose functions to
> draw, when it’s not an expose event, as being incorrect.
> 
> i.e. this:
> 
> > > 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.)
> > 
> > You can laugh, if you want, but I still think it's abuse, and won't
> > be convinced by being laughed at.
> 
> from http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00435.html
> 
> I can understand the argument to an extent, but I don’t have another
> solution.

We could discuss this again, perhaps the details have changed, or we
might be able o find some compromise everybody can live with.

For starters, what changes, if any, would you need to make in the
glyph matrices, and why?

Re: Change to NS drawing routines

[Alan Third]

On Mon, Aug 13, 2018 at 10:10:41PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 13 Aug 2018 19:46:59 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: emacs-devel@gnu.org
> > 
> > Going through the previous email discussions, linked in the thread
> > above, Eli made it clear that he sees using the expose functions to
> > draw, when it’s not an expose event, as being incorrect.
> > 
> > i.e. this:
> > 
> > > > 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.)
> > > 
> > > You can laugh, if you want, but I still think it's abuse, and won't
> > > be convinced by being laughed at.
> > 
> > from http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00435.html
> > 
> > I can understand the argument to an extent, but I don’t have another
> > solution.
> 
> We could discuss this again, perhaps the details have changed, or we
> might be able o find some compromise everybody can live with.
> 
> For starters, what changes, if any, would you need to make in the
> glyph matrices, and why?

For this none, I can do it all in the NS specific code.

I’ve changed all the NS drawing functions to check whether they are
allowed to draw. If not then I mark the area as dirty.

I’ve added an ns_flush_display function that I believe is called at
the end of redisplay (flush_frame). I wasn’t sure about this but it
looks as though it works, (i.e. everything draws OK) so I assume it’s
safe.

Anyway, ns_flush_display asks Cocoa/GNUstep to redraw the frame, which
results in drawRect being called which calls expose_frame on the
rectangles that have been marked as dirty.
-- 
Alan Third

Re: Change to NS drawing routines

[Eli Zaretskii]

> Date: Mon, 13 Aug 2018 20:36:04 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: charles@aurox.ch, emacs-devel@gnu.org
> 
> > > from http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00435.html
> > > 
> > > I can understand the argument to an extent, but I don’t have another
> > > solution.
> > 
> > We could discuss this again, perhaps the details have changed, or we
> > might be able o find some compromise everybody can live with.
> > 
> > For starters, what changes, if any, would you need to make in the
> > glyph matrices, and why?
> 
> For this none, I can do it all in the NS specific code.
> 
> I’ve changed all the NS drawing functions to check whether they are
> allowed to draw. If not then I mark the area as dirty.
> 
> I’ve added an ns_flush_display function that I believe is called at
> the end of redisplay (flush_frame). I wasn’t sure about this but it
> looks as though it works, (i.e. everything draws OK) so I assume it’s
> safe.
> 
> Anyway, ns_flush_display asks Cocoa/GNUstep to redraw the frame, which
> results in drawRect being called which calls expose_frame on the
> rectangles that have been marked as dirty.

In that case, I don't see why would I object.  My objection was to
introducing platform specific stuff into platform-independent code in
xdisp.c and dispnew.c, and/or into data structures these files use as
part of the display engine.  By contrast, it sounds like you just
caused the expose event to be triggered under special circumstances,
perhaps much more frequently than before, but when exactly the expose
event comes in on different window-systems is not something that is
against Emacs expectations, and certainly doesn't bother me.

Thanks.

Re: Change to NS drawing routines

[Charles A. Roelli]

> Date: Mon, 13 Aug 2018 19:46:59 +0100
> From: Alan Third <alan@idiocy.org>
> 
> from http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00435.html
> 
> I can understand the argument to an extent, but I don’t have another
> solution.

Thanks for the pointer.

By the way, I noticed that one of the problems YAMAMOTO Mitsuharu
discovered with the current way of drawing is fixed in your branch:

> Link:		https://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00440.html
>
> (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.)

It's a small detail, but neat nevertheless.

> > > My experience so far is that performance is not noticeably slower than
> > > master, however if someone with a slower Mac could try it that would
> > > be helpful.
> > 
> > I don't notice a speed difference compared to master on my slow box
> > running macOS 10.6.  Do we have any benchmarks that we could use to
> > check?
> 
> Unfortunately I’m not aware of any. I’m tempted to say that if there
> is no clear performance penalty, then it’s not a problem.

I tried M-x benchmark RET (redisplay) RET in master and in
scratch/ns-drawing, with scratch/ns-drawing often being faster in the
middle of big files like xdisp.c.  But I don't remember if I messed
with compiler options recently, so it would be good if somebody else
could check.

Re: Change to NS drawing routines

[Alan Third]

On Wed, Aug 15, 2018 at 09:20:17PM +0200, Charles A. Roelli wrote:
> 
> By the way, I noticed that one of the problems YAMAMOTO Mitsuharu
> discovered with the current way of drawing is fixed in your branch:
> 
> > Link:		https://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00440.html
> >
> > (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.)
> 
> It's a small detail, but neat nevertheless.

Ah, nice. My version of macOS doesn’t display that handle, so I was
unaware. Although now I look the rounded corners at the bottom no
longer disappear when the frame is resized. Cool. :)

> I tried M-x benchmark RET (redisplay) RET in master and in
> scratch/ns-drawing, with scratch/ns-drawing often being faster in the
> middle of big files like xdisp.c.  But I don't remember if I messed
> with compiler options recently, so it would be good if somebody else
> could check.

I see a slight improvement too, but it’s really too small to measure.
Expanding on your test above I tried this with benchmark from the top of
xdisp.c:

(dotimes (n 100) (scroll-up) (redisplay))

But now I try it again the improvement I saw has disappeared. If there
is a change in performance it appears to be too small to reliably
measure. Which is, if not good, at least not bad. :)

I’ve just realised this has reintroduced an annoying flicker on resize
(bug#30699) if you run something like:

    (dotimes (n 10)
      (sit-for 0.3)
      (set-frame-width nil (+ n 80)))

-- 
Alan Third

Re: Change to NS drawing routines

[Alan Third]

On Tue, Aug 14, 2018 at 05:50:08PM +0300, Eli Zaretskii wrote:
> 
> In that case, I don't see why would I object.  My objection was to
> introducing platform specific stuff into platform-independent code in
> xdisp.c and dispnew.c, and/or into data structures these files use as
> part of the display engine.  By contrast, it sounds like you just
> caused the expose event to be triggered under special circumstances,
> perhaps much more frequently than before, but when exactly the expose
> event comes in on different window-systems is not something that is
> against Emacs expectations, and certainly doesn't bother me.

OK, thanks for clearing that up for me. I’ll continue with this
approach.
-- 
Alan Third