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.

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.

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.

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]

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?

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):

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.

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.

Thanks for the sanity check and the threading heads-up arekkusu. Always appreciated.

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.

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.

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.

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.

http://onesadcookie.com/svn/repos/Kiloplane is where I see the difference. From memory, 1.5x faster..

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.