Now I am porting some OpenGL tutorials from win/glut to cocoa/mac os x. In the windowed mode everything works, but when context switches to fullscreen, screen may be empty (only clear colour)! For example: in the first, second, third times cube is, but in the fourth time cube is not. Even if app launches in fullscreen without sharing context. I don`t understand.
Xcode 3.2.1, Mac OS X 10.6.2
source link
It looks like AFController's enterFullScreen method probably needs to set up the OpenGL context ([scene initGL]).
Also, awakeFromNib may be called before the application is ready to draw, so perhaps it's not the best place for [scene initGL]. I suggest implementing NSApplication's delegate method, applicationDidFinishLaunching:, and moving [scene initGL] there. Just to be safe, you might also try calling NSOpenGLContext's makeCurrentContext from there as well.
Related
In OpenGL I implicitly create a graphics context with something like GLUT when I create a window. Suppose I drag my window into a monitor driven by a different video card (e.g. Intel embedded graphics on one and NVidia on another). Who renders the window? I.e. which device runs the graphics pipeline for each of the cases below.
The glGetString(GL_RENDERER) seems to always return the primary display (where the GLUT window was created) even if I drag the window fully into one window or the other. (I am guessing it all gets done by the primary...) Can someone help me understand this?
Note, using Windows 10, GLUT, OpenGL, but I ask the questions in general if it matters.
GL knows nothing about windows, only about contexts. GL renders to the framebuffer in the current context.
You may code a way of asking the OS about where a window is, and use two context, and set as current the proper one depending on OS answer.
I'm using NSOpenGLContext to optimize drawing AU plugins. There are multiple plugins and each can have multiple instances. So each plugin creates a global NSOpenGLContext and attach particular NSView contexts to it, so that the textures do not need do be duplicated.
Problem: When I open one plugin, it's ok. I open a different on, it's ok. Now I release the first one, it destroys all resources => the second one looses its textures!
I checked that both context are different, sharing is different, they both use makeCurrentContext in both lockFocus and drawRect. Any ideas what is wrong here?
Btw.I got the same thing working using AGL and WGL (on Windows), both without problems, so it is just Cocoa as usual.
Ok I think I found a solution - one needs to call [NSOpenGLContext clearCurrentContext]; after any painting or any processing. Why? No idea... I'm considering it yet another bug in Mac OS X...impossible pseudosystem...
I am creating a music-eduaction app that reads in musical scores - not audio files - and will need to present an animated graphical screen. I created a document-based app to make file access easy, and I have it now reading and parsing the files, and I have all the song data stored in my Obj-C classes. I also have a textview in my xib that I can write song attributes and other text tidbits to. Now I want a second view, which needs to be graphical and animatable, for the music. I am an Xcode novice, but have some openGL experience. My setup is latest OS and Xcode versions.
When I try to drag the OpenGL View into my window in IB, I get a weird error/warning that says "Unsupported Configuration - NSOpenGLView in One Shot memory enabled window" (so that is weird), and the openGL view does not appear when I run the app.
I can't find much reference to OpenGL Views in NSdocuments on this site, or anywhere else, which makes me think I might be trying to do something that is not meant to be done. Does anyone have any advice for me? Should I not use a document-based app? Should I use something other than openGL? Or maybe I need to build the openGL View and View Controller 100% programmatically in this case? Any advice or pointers to some applicable samples/tutorials would be a huge help.
Try disabling the "One Shot" option from the Windows's memory attributes in Interface Builder.
From NSWindow documentation:
setOneShot: Sets whether the window device that the window manages
should be freed when it’s removed from the screen list.
- (void)setOneShot:(BOOL)oneShot
Parameters
oneShot YES to free the window’s window device when it’s removed from the screen list (hidden)
and to create another one when it’s returned to the screen; NO to
reuse the window device.
Discussion
Freeing the window device when
it’s removed from the screen list can result in memory savings and
performance improvement for NSWindow objects that don’t take long to
display. It’s particularly appropriate for NSWindow objects the user
might use once or twice but not display continually.
The client for the MMO I work on uses two contexts, one for a window view and one fullscreen. I'm wondering if I just use a window sized to the display I can simply resize it if the user wants a smaller window so they can access their desktop.
Is their a performance penalty for running opengl in a window vs fullscreen assuming the same dimensions etc?
The client shell is written in cocoa; the game code itself is cross-platform.
We only support OSX 10.5 and 10.6 for the next release.
Before 10.6, if your context did not have the full screen flag in it's creation, then you had a small performance difference. Now, with 10.6, this has changed.
Have a look at:
http://lists.apple.com/archives/Cocoa-dev/2009/Sep/msg01054.html
if there is a cost associated with clipping each frame, then yes.
Can anyone provide a sample / link to a sample Cocoa app that changes the 'hardware' cursor in a fullscreen OpenGL Cocoa app? I have been able to create a full screen GL app and an app that changes the cursor by overriding NSView::resetCursorRects but I have not been able to get both to work simultaneously. I've also refitted some of the Apple GL samples (CocoaGL, Custom Cocoa OpenGL, etc) by overriding NSView::resetCursorRects and I haven't been able to get the cursor to change in fullscreen in them either. I have the book "OpenGL Programming on Mac OS X" which also avoids the problem.
#Christopher: I hadn't tried [NSCursor set]. Good call but I made a run at it and no luck. It still returns to the system cursor. I'd say that perhaps something is overriding it in my calls that switch to fullscreen but I've actually tried reseting the mouse cursor in my NSView's draw routine (which gets called repeatedly) and the cursor never switches from the system default.
Try using NSCursor directly, the NSView cursor rect methods depend on things such as a properly sized and visible NSWindow to work properly which aren't necessarily the case in full screen mode.