3 ms·

There’s quite a few approaches, it’s hard to figure out which one is appropriate for this one. I think that enabling setNeedsDisplay and dispatching commands as

There’s quite a few approaches, it’s hard to figure out which one is appropriate for this one. I think that enabling setNeedsDisplay and dispatching commands asynchronously might do the trick? With asynchronous dispatch I’ve actually been getting 120 FPS. But it’s very much case by case basis and I might not be understanding the use case. IIRC this project Gets to 120 when you drag your mouse https://github.com/jtbandes/metalbrot-playground https://github.com/jtbandes/metalbrot-playground

trishume 9y ago
I have a lot of avenues to test but unfortunately testing each one requires setting up a sample app with signposts and recording a bunch of runs in Instruments, so there's a bit of work to do if I want to figure out the right way. And do you have a 120fps+ monitor? If not I'm not sure what you mean by 120fps unless it's broken or not vsynced at all and painting twice per frame. If you have a proper way of waiting on vsync 120fps is just a waste of power with no benefits and you don't want that.
- adamnemecek 9y ago
  Haha welcome to gpu programming. You should hit up Warren Moore on Twitter (@warrenm), he’s a real life savior. Re: 120fps, I questioned it myself but the difference is perceivable. Idk if something is broken or not I was confused too. Re power consumption, that’s why you enable setneedsdisplay.
  - trishume 9y ago
    Maybe the reason that 120fps is perceivably better is that your draw calls don't line up with vsync, so doubling the number of frames eliminates the dropped frame effect in @jordwalke's diagram! And thanks for the Twitter recommendation, I followed him.
jvz 9y ago
> IIRC this project Gets to 120 when you drag your mouse What causes that kind of thing? I've noticed stuff like that while playing video in mpv sometimes (despite my Mac being easily fast enough to play the video) and it just baffles me.
- Doxin 9y ago
  Moving the mouse has a tendency to send various events to windows. Sometimes just the mousemotion event is enough to trigger the program to redraw. I'm not sure how cursors are implemented on osX but it might just be marking the bit under the cursor dirty, triggering a redraw.

trishume 9y ago

I have a lot of avenues to test but unfortunately testing each one requires setting up a sample app with signposts and recording a bunch of runs in Instruments, so there's a bit of work to do if I want to figure out the right way. And do you have a 120fps+ monitor? If not I'm not sure what you mean by 120fps unless it's broken or not vsynced at all and painting twice per frame. If you have a proper way of waiting on vsync 120fps is just a waste of power with no benefits and you don't want that.

adamnemecek 9y ago
Haha welcome to gpu programming. You should hit up Warren Moore on Twitter (@warrenm), he’s a real life savior. Re: 120fps, I questioned it myself but the difference is perceivable. Idk if something is broken or not I was confused too. Re power consumption, that’s why you enable setneedsdisplay.
- trishume 9y ago
  Maybe the reason that 120fps is perceivably better is that your draw calls don't line up with vsync, so doubling the number of frames eliminates the dropped frame effect in @jordwalke's diagram! And thanks for the Twitter recommendation, I followed him.

jvz 9y ago

> IIRC this project Gets to 120 when you drag your mouse What causes that kind of thing? I've noticed stuff like that while playing video in mpv sometimes (despite my Mac being easily fast enough to play the video) and it just baffles me.

Doxin 9y ago
Moving the mouse has a tendency to send various events to windows. Sometimes just the mousemotion event is enough to trigger the program to redraw. I'm not sure how cursors are implemented on osX but it might just be marking the bit under the cursor dirty, triggering a redraw.