macOS graphics performance

macOS graphics performance

[Alan Third]

I've pushed some work I've done on the NS port's graphics to
scratch/ns/performance. I would appreciate it if people running
various versions of macOS give it a go. It should only improve things
for people running macOS 10.14 and above, but I'd still appreciate
knowing whether it breaks anything on older macOS versions.

Thanks!
-- 
Alan Third

Re: macOS graphics performance

[Andrii Kolomoiets]

Alan Third <alan@idiocy.org> writes:

> I've pushed some work I've done on the NS port's graphics to
> scratch/ns/performance.

Cool!

> I would appreciate it if people running various versions of macOS give
> it a go. It should only improve things for people running macOS 10.14
> and above, but I'd still appreciate knowing whether it breaks anything
> on older macOS versions.

The Emacs frame is totally "empty" for me.  No text is drawn.

In GNU Emacs 28.0.50 (build 2, x86_64-apple-darwin20.2.0, NS
appkit-2022.20 Version 11.1 (Build 20C69))
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.1

Re: macOS graphics performance

[Alan Third]

On Mon, Dec 28, 2020 at 12:33:07AM +0200, Andrii Kolomoiets wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > I would appreciate it if people running various versions of macOS give
> > it a go. It should only improve things for people running macOS 10.14
> > and above, but I'd still appreciate knowing whether it breaks anything
> > on older macOS versions.
> 
> The Emacs frame is totally "empty" for me.  No text is drawn.

Thanks for testing! I think this is probably down to the pixel format,
which I don't even begin to understand the logic behind.

Can you please try again with this patch:

modified   src/nsterm.m
@@ -9596,7 +9596,7 @@ - (CGContextRef) getContext
             (id)kIOSurfaceHeight:[NSNumber numberWithInt:size.height],
             (id)kIOSurfaceBytesPerRow:[NSNumber numberWithInt:bytesPerRow],
             (id)kIOSurfaceBytesPerElement:[NSNumber numberWithInt:4],
-            (id)kIOSurfacePixelFormat:[NSNumber numberWithUnsignedInt:'RGBA']});
+            (id)kIOSurfacePixelFormat:[NSNumber numberWithUnsignedInt:'BGRA']});
     }
 
   IOReturn lockStatus = IOSurfaceLock (surface, 0, nil);
@@ -9613,7 +9613,8 @@ - (CGContextRef) getContext
                                    8,
                                    IOSurfaceGetBytesPerRow (currentSurface),
                                    colorSpace,
-                                   IOSurfaceGetPixelFormat (currentSurface));
+                                   (kCGImageAlphaPremultipliedFirst
+                                    | kCGBitmapByteOrder32Host));
   return context;
 }

-- 
Alan Third

Re: macOS graphics performance

[Daniel Martín]

Alan Third <alan@idiocy.org> writes:

> I've pushed some work I've done on the NS port's graphics to
> scratch/ns/performance. I would appreciate it if people running
> various versions of macOS give it a go. It should only improve things
> for people running macOS 10.14 and above, but I'd still appreciate
> knowing whether it breaks anything on older macOS versions.
>
> Thanks!

Thanks! It seems to work fine here (10.15.7), although I had to apply
your additional patch, as I experienced the same problem as Andrii.

Is there any thread with more context about the performance changes in
the scratch/ns/performance branch? What should I focus my testing on?

Re: macOS graphics performance

[Alan Third]

On Mon, Dec 28, 2020 at 01:05:02AM +0100, Daniel Martín wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > I've pushed some work I've done on the NS port's graphics to
> > scratch/ns/performance. I would appreciate it if people running
> > various versions of macOS give it a go. It should only improve things
> > for people running macOS 10.14 and above, but I'd still appreciate
> > knowing whether it breaks anything on older macOS versions.
> >
> > Thanks!
> 
> Thanks! It seems to work fine here (10.15.7), although I had to apply
> your additional patch, as I experienced the same problem as Andrii.

Ah, good to know, thanks!

> Is there any thread with more context about the performance changes in
> the scratch/ns/performance branch? What should I focus my testing on?

I've not written anything about it specifically. It's a continuation
of the work that was done in the master branch a long time ago to make
it draw to an off-screen buffer.

Basically, in the master branch, it draws to a buffer, and then that
buffer is copied into an image and handed to the GUI toolkit for
display. The copying is a requirement of the type of buffer I was
using.

This branch draws into a different type of buffer which doesn't
require us to make another copy, then it's handed to the GUI toolkit
for display. These buffers also have some advantage in that they're
copied to the VRAM asynchronously, whereas the other ones aren't.

Because of the asynchronous copying I've had to use more buffers (at
least two), and so there is a copy added back in to make sure they're
all kept up to date. But it's still noticeably faster when there are a
lot of large updates, for example in scrolling.

I think in situations where there are a lot of small independent
updates, like moving the point extremely quickly, it may be slower.

I also rewrote the scrolling code, as I realised I have full access to
the pixels and can copy them around with memcpy and friends. I tried
porting that to the master branch, but it didn't have as large an
effect as I'd hoped.

So, basically, anything that involves drawing to the screen should,
hopefully, be faster. Probably the biggest difference will be for
people with large frames on hi-res screens scrolling around large
buffers.
-- 
Alan Third

Re: macOS graphics performance

[Daniel Martín]

Alan Third <alan@idiocy.org> writes:

>
> Because of the asynchronous copying I've had to use more buffers (at
> least two), and so there is a copy added back in to make sure they're
> all kept up to date. But it's still noticeably faster when there are a
> lot of large updates, for example in scrolling.

Yes, I notice a much smoother scrolling performance.

> So, basically, anything that involves drawing to the screen should,
> hopefully, be faster. Probably the biggest difference will be for
> people with large frames on hi-res screens scrolling around large
> buffers.

I've tested scrolling and moving the point in a buffer with xdisp.c and
display performance feels much better.  The setup I used is several
vertical frames on a retina display (no external monitor yet).

Re: macOS graphics performance

[Andrii Kolomoiets]

Alan Third <alan@idiocy.org> writes:

> Can you please try again with this patch:

Works fine with patch applied, thanks!

Will use this version from now on.

Re: macOS graphics performance

[Philipp Stephani]

Am So., 27. Dez. 2020 um 18:24 Uhr schrieb Alan Third <alan@idiocy.org>:
>
> I've pushed some work I've done on the NS port's graphics to
> scratch/ns/performance. I would appreciate it if people running
> various versions of macOS give it a go. It should only improve things
> for people running macOS 10.14 and above, but I'd still appreciate
> knowing whether it breaks anything on older macOS versions.

It seems to work fine on Big Sur/Apple Silicon. Haven't tested it very
thoroughly, though.

Re: macOS graphics performance

[Doug Davis]

Alan Third <alan@idiocy.org> writes:

> So, basically, anything that involves drawing to the screen should,
> hopefully, be faster. Probably the biggest difference will be for
> people with large frames on hi-res screens scrolling around large
> buffers.

This is exactly what I'm experiencing on macOS Big Sur. Scrolling
performance is improved quite a bit. Thanks a lot for your work on this!

    Doug

Re: macOS graphics performance

[Alan Third]

On Sun, Dec 27, 2020 at 05:23:28PM +0000, Alan Third wrote:
> I've pushed some work I've done on the NS port's graphics to
> scratch/ns/performance. I would appreciate it if people running
> various versions of macOS give it a go. It should only improve things
> for people running macOS 10.14 and above, but I'd still appreciate
> knowing whether it breaks anything on older macOS versions.

I've pushed this to master, even though nobody running an old version
of macOS has responded.

Thanks to everyone who did test it.
-- 
Alan Third