sokol_app.h: macOS with GLCORE33 mouse position update is noticeably laggy

[slmjkdbtl]

#define SOKOL_IMPL
#define SOKOL_GLCORE33
// #define SOKOL_METAL

#include "sokol_app.h"

void event(const sapp_event* e) {
	printf("%f, %f\n", e->mouse_x, e->mouse_y);
}

sapp_desc sokol_main(int argc, char* argv[]) {
	return (sapp_desc){
		.event_cb = event,
	};
}

toggling between SOKOL_GLCORE33 and SOKOL_METAL can tell the mouse position update with GLCORE33 is laggier, it's more obvious if drawing something at mouse position

[floooh]

I don't think I can do much about that. The mouse event code is the same between the Metal and GL backends in sokol_app.h, it might be that NSOpenGLView has more latency for presenting the framebuffer than MTKView. I'll check for any obvious things (like triple- vs double-buffering), but it's unlikely that it's something as simple as that.

PS: one thing you could try is adding [NSEvent setMouseCoalescingEnabled:NO] towards the end of applicationDidFinishLaunching: and see if this reduces latency, I'm currently working on the pointer-lock feature and have seen this function in various other code bases when pointer-lock is activated. Apparently it reduces "mouse latency". It would be strange though if MTKView activates this but NSOpenGLView doesn't.

If this works we can probably add this generally. However the function isn't really documented (see: https://developer.apple.com/documentation/appkit/nsevent/2870068-mousecoalescingenabled?language=objc), so I don't know what's the pros and cons.

[slmjkdbtl]

[NSEvent setMouseCoalescingEnabled:NO] did make the mouse event reporting more frequent (the printing frequency in the example above is higher), but it still seems a little bit laggier than with SOKOL_METAL (there's no obvious improvement if I draw stuff at mouse position). Thanks! I'll try do more research on this topic

[slmjkdbtl]

I found that if I remove the setNeedsDisplay in timerFired impl it seem to report smooth mouse motion in the mouseMoved event, is it possible the timer is somehow interfering with the view / event update? (Also I didn't see other windowing libs uses a NSTimer and setNeedsDisplay for updating view, maybe there's an alternative way without a timer?)

[floooh]

Hmm ok, worth a try (however, isn't the display frozen if the setNeedsDisplay is removed?). IFIR had to add the NSTimer code because I couldn't get the CVDisplayLink method described here to properly work after the macOS Catalina GL regressions:

https://developer.apple.com/library/archive/qa/qa1385/_index.html

[floooh]

Closing this with the mouse latency improvements for macOS that had just been merged. It's still not perfect, but very noticeably better.