Change cursor in GL fullscreen on OSX using cocoa? - cocoa

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.

Related

OpenGL Context with Multiple Devices (Monitors)

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.

Creating NSOpenGLView inside an NSDocument (OS X)

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.

Render OpenGL on background thread and still work with Cocoa Controls in Mac OSX

I am working on a mac osx control that is OpenGL based. Currently I am using an NSOpenGLView and a CVDisplayLink to coordinate my rendering on a background thread. This works great, but I need to allow Cocoa controls to be displayed over this OpenGL based control.
I realize you can do this with putting your Cocoa controls in borderless windows, however, that doesn't seem like a very good workflow for my users.
Alternatively I can make the view layer-backed and I got that working, however I don't like rendering my OpenGL content on the main thread, sometimes it blocks the main thread when the frame-rate dips.
Are there any samples that show how to achieve the best of both worlds?
The background thread for rendering is completely irrelevant. You just need to enable layer-backing for the views and then the subviews/controls will be composited correctly on top of your OpenGL content. You can also use CAOpenGLLayer for more explicit layering with CALayers.

Managing interface builder's window layout

I have my macbook pro hooked up to an apple cinema display. I want to work on my code on the laptop but have interface builder on the cinema display. It needs to be this way because my laptop screen doesn't have the resolution to show a full iPad interface layout in IB so I would need to scroll up and down.
The thing I am fighting with is that whenever I open a XIB, or when IB starts, it places any new app windows back on my laptop screen. Is there any way to define a window layout for IB to use, and tell it to start all windows on my second screen by default? Thanks
Unfortunately Interface Builder does not currently save window positions (which include what screen they're on).
You might have limited success using Spaces, which assigns specific applications to specific spaces, but I'm not sure how it would work with multiple screens.

Problem with fullscreen OpenGL on the Mac

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.

Resources