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