Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Hello,
I'm making a graphical application for Mac OS. I've found several examples of how to create a context on Cocoa form, but all of them involve either NSOpenGlView, or custom view. The question is, is it possible to create a context directly on a window? I'm asking this mostly because of speed concerns, NSOpenGlView clearly renders to a buffer and then draws it on screen.
i don't know what NSOpenGlView does, but i can tell you any api is going to render to a buffer, then present that buffer to the screen. presenting to the screen is usually just a simple change of a pointer, so its very fast. If you don't have a backbuffer, and your rendering directly to the front buffer (the buffer currently presenting to the screen), you'll usually end up seeing tears since you may be in the middle of rendering to the buffer while the screen is reading from it
1 hour ago, mullich said:The question is, is it possible to create a context directly on a window?
No, not with modern APIs. NSView subclasses are the drawing and compositing mechanism for Cocoa, so you must use them to do any drawing or compositing, including via OpenGL. Creating a GL context "for a window" in Cocoa is largely meaningless and wouldn't be any "faster." It's like asking to create an OpenGL context for a NSError object.
You can create a custom NSView subclasses though, and build your OpenGL use around that. It isn't any faster per se, but it does afford you more control (at the cost of usability).
As iedoc notes, the whole rendering-to-a-buffer-and-flipping thing is what you want to do, otherwise you get artifacts that you can't control for since you don't have that level of control over the graphics hardware on any modern OS. The flipping is not slow.
If you're really that worried about every little microsecond and you have a good reason to be, you should drop OpenGL anyway. Metal is significantly better at giving you low level control over what matters, and Apple clearly cares much more about it than OpenGL, so this is only going to become more apparent. It is slightly harder to use, however.
I have another problem. While resizing, view updates lag behind, so there is white (MacOS 10.8) or black (MacOS 10.12) frame near the border which I'm resizing. I'm using WindowDidResize event, is this correct? I've also tried StartLiveResize and EndLiveResize, but it's even worse.
Oh, and I looked up examples of resizing OpenGL in Cocoa, and they recommend calling glViewport, but it only helps then I'm decreasing size of window, not increasing it.
