> On Nov 11, 2018, at 6:55 AM, qemu-devel-requ...@nongnu.org wrote: > > The code for the cocoa stuff is in ui/cocoa.m. Quick notes on structure: > > * there is a weird thing where cocoa.m provides its own main(), and arranges > that the function which is main() for every other UI is renamed qemu_main() > and called later (I'd like to get rid of that one day if we could, it's just > weird) > * cocoa_display_init() is the "initialize the display" entry point -- this > will always be called from on the main thread (strictly, from whichever > thread OSX calls our applicationDidFinishLaunching callback on, but I assume > that's the main thread) > * the runtime entry points into the cocoa UI code are just the functions in > the DisplayChangeListener struct: cocoa_update(), cocoa_switch() and > cocoa_refresh() > > Arranging for the last 3 to schedule their operation onto the main > thread is probably what's needed. Things I don't know: > > * should this "run thing on main thread" be synchronous or asynchronous? > (sync is probably safest) synchronous sounds good.
> * what's the right OSX API to do this? https://developer.apple.com/documentation/objectivec/nsobject/1414900-performselectoronmainthread?language=objc > * how can we most cleanly do this in a way that still works on OSX 10.6 (the > oldest we currently support)? (I suspect we'll need ifdefs and fall back to > "just run on this thread" on older versions) I would make another function called switchSurfaceInternal: and then move all the code from switchSurface: to this new function. Then have the switchSurface: method call the switchSurfaceInternal: method by using [performSelectorOnMainThread:withObject:waitUntilDone:]. The call would look like this: [self performSelectorOnMainThread: @selector(switchSurface:) withObject: surface waitUntilDone: YES] I'm not sure if waitUntilDone should be set to YES. QEMU might work faster if it is set to NO. Thank you.
