GLUT apple menu close application

Luminary
Posts: 5,143
Joined: 2002.04
Post: #16
It's nothing fancy, just a bit of a convenience. Certainly, no performance benefits to not using it, nor any pixel format attributes you can't get with it.
Quote this message in a reply
Member
Posts: 100
Joined: 2006.05
Post: #17
AnotherJake Wrote:What do you mean by `jitters'? What were you using for your pixel format? Were you mistakenly trying to use NSOpenGLPFAStereo or something? If NSView is really better than NSOpenGLView performance-wise then that is *really* important! I am a bit surprised here that NSOpenGLView sounds like such a bad subclass of NSView to begin with. I am skeptical but I'll stop using it if there is something wrong with it. I have seen absolutely nothing wrong with it for years, and I have used it a LOT, so I am very curious about this.

There were (brief) ghost images, the kind that are a sure sign of the lack of double buffering. I had very basic PFA's (nothing like Stereo) including NSOpenGLPFADoubleBuffer. My guess is that the pixel format I was coding was being 'overwritten' by the NIB file upon load. Maybe I set them in the incorrect spot, or maybe I'm just clumsy, I can't remember. Either way, it was certainly a double buffering problem (not vsync, I took care of that). If you've been using it without problems, there's probably no reason to tamper with it unless you hit some problems. Re-coding it may cause more problems than it will fix. I can't imagine why one would have better performance than the other... The key here is flexibility.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #18
Nevada Wrote:...Re-coding it may cause more problems than it will fix...

If I could get any solid confirmation that there is good reason not to use NSOpenGLView then I would not use it -- re-coding is not an issue for me at all (especially the view, which is very simple). It would be helpful if you could reproduce the problem. Otherwise I would maintain that NSOpenGLView should be considered rock-solid, and not to be avoided.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #19
I should add that I am in no way opposed to subclassing NSView directly. There really isn't much extra that comes with NSOpenGLView when it comes down to actual usage. I wind up piling a lot of other stuff on top of it anyway. I guess as it stands from this little discussion, I don't see any particular reason to go NSOpenGLView or NSView -- either way gets to the same result as far as I can see. And I don't see any more or less extra flexibility in using either... [shrugs]
Quote this message in a reply
Member
Posts: 100
Joined: 2006.05
Post: #20
I probably set the pixel format in the wrong place. I believe I did it in the initWithFrame: method. Where do you set your pixel format attributes?
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #21
In initWithFrame. Here's a typical example (contextInit just gets called at the top of initWithFrame to help separate the code out a bit -- nothing tricky):
Code:
- (void)contextInit:(NSRect)frameRect
{
    NSOpenGLPixelFormat        *fullScreenPixelFormat, *windowedPixelFormat;
    NSOpenGLPixelFormatAttribute    attribs[] = {
                    NSOpenGLPFAWindow,
                    NSOpenGLPFAColorSize, (NSOpenGLPixelFormatAttribute)32,
                    NSOpenGLPFADepthSize, (NSOpenGLPixelFormatAttribute)32,
                    NSOpenGLPFAStencilSize, (NSOpenGLPixelFormatAttribute)8,
                    NSOpenGLPFAAccumSize, (NSOpenGLPixelFormatAttribute)8,
                    NSOpenGLPFAAccelerated,
                    NSOpenGLPFADoubleBuffer,
                    NSOpenGLPFASingleRenderer,
                    NSOpenGLPFANoRecovery,
                    NSOpenGLPFAScreenMask,
                    CGDisplayIDToOpenGLDisplayMask(kCGDirectMainDisplay),
                    (NSOpenGLPixelFormatAttribute)0 };
    
    windowedPixelFormat = [[NSOpenGLPixelFormat alloc] initWithAttributes:attribs];
    if (windowedPixelFormat == nil)
        [self contextCreationFailure:@"Unable to create windowed pixel format."];
    attribs[0] = NSOpenGLPFAFullScreen;
    fullScreenPixelFormat = [[NSOpenGLPixelFormat alloc] initWithAttributes:attribs];
    if (fullScreenPixelFormat == nil)
        [self contextCreationFailure:@"Unable to create full screen pixel format."];
    self = [super initWithFrame:frameRect pixelFormat:windowedPixelFormat];
    if (self == nil)
        [self contextCreationFailure:@"Unable to create a windowed OpenGL context."];
    currentContext = [self openGLContext];
    fullScreenGLContext = [[NSOpenGLContext alloc] initWithFormat:fullScreenPixelFormat
                            shareContext:[self openGLContext]];
    if (fullScreenGLContext == nil)
        [self contextCreationFailure:@"Unable to create a full screen OpenGL context."];
   [windowedPixelFormat release];
   [fullScreenPixelFormat release];
}
Quote this message in a reply
Member
Posts: 100
Joined: 2006.05
Post: #22
I scrapped the old code a long time ago, but there's a chance I might have left out the

self = [super initWithFrame:frameRect pixelFormat:windowedPixelFormat];

part. I can't think of any other reason why yours would work and mine wouldn't. Oh well. I'm still happy with my NSView.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #23
AnotherJake Wrote:The IB palette glView is junk. I'm not sure why they have it in there.

So it makes the next version look better, of course.


AnotherJake Wrote:If I could get any solid confirmation that there is good reason not to use NSOpenGLView then I would not use it

NSOpenGLView is fine, you just need to set up the pixel format manually if you want to do anything useful.

Subclassing NSView from scratch is also OK, and a useful learning experience. Just be wary of threading issues.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #24
Thanks for the sanity check and the threading heads-up arekkusu. Always appreciated. Smile
Quote this message in a reply
Member
Posts: 81
Joined: 2007.07
Post: #25
Hello again guys, thanks for the suggestions, I am using GLUT for a shipping game and its working quite nicely, I simply open a single buffered window and blit to it using glDrawPixels, at 1024x768 on a GMA 950 I am getting 50+ fps (including all my game logic) which is more than acceptable. I will probably try a glTexSubImage method next go around, but I don't see why that would improve anything since the same amount of data is still being transfered over the bus, which is the slow part.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #26
I'm surprised you're getting that kind of performance out of glDrawPixels. I'm not sure I would count on it being that solid across different machines though. The gma950 uses shared system memory for VRAM so there there is a possibility it's already there and doesn't require a transfer, but I do not know specific implementation details. For comparison, I do know that I don't get any different speed using VBOs on the gma950, so I *suspect* that there is no movement of memory, but again I have no idea. Other machines will have separate VRAM on-card and (for sure) will require a transfer to get that data there. I don't know the details with glDrawPixels, but I know for a fact you can get an automatic DMA transfer boost if you use glTexSubImage2D.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #27
DrawPixels is the slow path, that's true, though on a GMA 950 if the source and destination pixel formats are the same, it might be little less efficient than a memcpy.

On a discrete graphics card, the data has to be transfered across the PCIe bus, and your application will be blocked whilst this happens unless you're using a PBO, so it'll be slow.

VBOs won't show any performance increase on the GMA 950 unless you turn on the MP engine, in which case they are a major performance improvement.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #28
OneSadCookie Wrote:VBOs won't show any performance increase on the GMA 950 unless you turn on the MP engine, in which case they are a major performance improvement.
Not that I've seen. MP engine does nothing for VBO performance on my Mini. I made extra double sure both MP and VBOs were enabled, and... nada, zero, zilch, zippo performance increase.

That said, most of the application is just drawing, with no other processor intensive stuff like physics or collision, etc. Perhaps then one might see a boost.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #29
http://onesadcookie.com/svn/repos/Kiloplane is where I see the difference. From memory, 1.5x faster..
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #30
OneSadCookie Wrote:http://onesadcookie.com/svn/repos/Kiloplane is where I see the difference. From memory, 1.5x faster..
I definitely would like to investigate that and see if I can track down if I'm doing something wrong then. Is there any way to simply download that entire directory in one click? I am ignorant of svn.Sad
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  SDL and menu bar on OS X A_SN_ 9 9,430 Feb 7, 2012 11:51 AM
Last Post: trailmix
  Can't get menu bars to work. XSTNX 0 2,346 Jun 26, 2009 09:08 AM
Last Post: XSTNX
  OpenGL Menu engine? BinarySpike 4 7,309 Jun 11, 2007 09:43 PM
Last Post: JeroMiya
  Remove the File Menu from app guvidu 2 3,379 Mar 23, 2007 12:43 PM
Last Post: PowerMacX
  Enabling the "quit" menu function in an SDL program ferum 2 4,124 Sep 10, 2006 02:35 PM
Last Post: PowerMacX