I am currently developing a c++ application framework on osx (I am on the osx version right now, will become cross platform) and I ran into the following issue: Basically my application class is entirely event driven. I also wrote my own Timer/Callback (not using NSTimer though and thus only related to my own event loop and not NSApplications) class in c++ that simply adds events to my Applications event queue so that they get fired from the mainthread. Now, I am basically letting one of those timers fire as fast as possible to call my Windows draw function which basically looks like this (pseudocode):
void myCocoaWindow::draw()
{
enableNSOpenGLContext();
//perform drawing
//Swap buffers
[[m_glView openGLContext] flushBuffer];
}
Everything works very good aslong as vertical sync is turned off. But as soon as I turn it on, the flushBuffer
function blocks until the next vertical retrace and thus blocks my whole event loop.
The following questions result from that:
- How is the NSApplication event loop handling that? if I implement the same behaviour using native cocoa code only, NSApplica开发者_运维问答tions event loop does not seem to be affected by the wait for vertical retrace?
- Can I maybe run the draw function in a secondary thread (and thus avoid the blocking inside my event loop)? That would require a threadsafe initialization and access of the appropriate NSOpenGLContext though, is that possible?
To clarify question two, I know I can lock all the functions related to the NSOpenGLContext myself, my question is rather if it is safe that nothing else will access the context that I don't have any control over!
精彩评论