Showing resize control over NSOpenGLView

Moderator
Posts: 3,572
Joined: 2003.06
Post: #1
Is there a way to get the resize control to show in the lower right corner of an NSOpenGLView where the view fills the entire window?
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #2
Faking it with a texture? Remember that on machines without Quartz Extreme enabled, anything over an OpenGL view will make it run MUCH slower.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #3
Wouldn't lines be faster in this case if it were to be faked? I think I can do a good job with it, but should it be faked? What happens if Apple eventually takes care of it themselves? What if they change the style of the resize control down the road? Should I wait to see what happens with Tiger? This has been bugging me since OS X 10.1. I've done some searching here, mamasam, and general google and haven't found a whisper of it (not that it's not out there).

I guess the reason I'm bringing it up is because I recently sent an alpha of a level editor I'm working on to a friend, who I trust, and has a lot of experience with Macs, and he had no idea that he could change the size of the window until I told him. This seems really wrong to me. I think I should put at least a hint down there or something.

So if it needs to be faked, then what should be the best procedure to do so? Check for version "this" and "that"? Add a check for the future if it never gets maintained? Should I really care and just fake it anyway and say Apple screwed up future versions?

I'm still holding out for a "proper" way to deal with this if it can be found here.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #4
If you really want this, just fake it with a little alpha blended textured quad in the corner of your scene. You can get the bitmap to use from the System resources with an app like ThemePark (/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/Extras.rsrc, pxm# 450, image 3 for Aqua and 4 for BM.)

The default view system doesn't do this, because the GL surface is floated on top of all the other Quartz surfaces. I think it's unlikely that Apple will change it in Tiger (though feel free to log a feature request!)
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #5
Just in case I made you think otherwise, I didn't mean fake a "white square with some drag lines in it", because that always looks awful! So awful that Apple added a little command line switch so you could decide wether you wanted them enabled in Java apps or not. The kind of "fake" drag corner I'm suggesting is just some "drag lines" in the corner, just as Preview does. And, no, drawing those lines as GL lines is a bad idea, since line antialiasing doesn't work in many graphic cards (just ask arekkusu Wink )

Go with the alpha blended quad, even if Apple decides to change the resize graphic in the future is unlikely that it will be much different (it has been the same since System 8)
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #6
Don't worry, the way it's done in Preview is exactly what I had in mind to begin with. I don't think those lines are anti-aliased though, not that it matters anyway since line drawing style can't be guaranteed across different renderers. I agree, the alpha blended quad is the way to go and it looks just like the real thing after trying it out. It still reallly bugs me that this is the way I have to do things to give any indication of resizability to the user. There's just no logical way, that I've been able to come up with, that would make this technique future-compatible. Make no mistake about it, this is a clumsy hack around an Apple mistake. If they are going to fix this, I hope they decide to make it an optional feature (at least initially) instead of forcing their fix over those of us who've had to fill the gap in the meantime.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #7
You could say the same thing about GL minimization, or fullscreen events, or splitview resizing, or a hundred other things. Nobody writes perfect code the first time, especially OS vendors. Writing an OS is hard! Yeah, we have to deal with backwards and forwards compatibility, but that's life.

At least your workaround doesn't involve using any private APIs Wink
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #8
arekkusu Wrote:You could say the same thing about GL minimization, or fullscreen events, or splitview resizing, or a hundred other things.
... like key up events not being sent with the cmd key... Yeah, I hear ya'. You're right, I shouldn't sound like such a pooh pooh about it. I've found over the years that often one of the more frustrating things about programming is running into situations like this where you wind up trying to second-guess the OS vendor. It's like trying to hit a moving target all the time. Not like this particular problem is such a huge deal, I realize it's just a realitively minor detail in the grander scheme of things. It just really bugged me, but I'm happy with the solution we seem to have agreed upon here. I really appreciate your input guys. Smile
Quote this message in a reply
Member
Posts: 320
Joined: 2003.06
Post: #9
you could always Shock leave a border around your view if it's resizable. I don't see why you'd want to have a windowed game that takes up the whole view anyway. Just chuck some text in there that says "Windowed Mode - Paused" and set full screen as the default, and you'll be right. Otherwise, if it's actually a windowed-style game, why isn't the score, lives left etc. written next to the OpenGLView rather than on top of it?

Chopper, iSight Screensavers, DuckDuckDuck: http://majicjungle.com
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #10
Because borders suck.
Quote this message in a reply
Moderator
Posts: 434
Joined: 2002.09
Post: #11
PowerMacX Wrote:Just in case I made you think otherwise, I didn't mean fake a "white square with some drag lines in it", because that always looks awful!

My game Black Cube showed the user that they could resize the window simply by drawing three white diagonal lines in the bottom corner. (The background was black for the entire window.) It didn't look awful, and several people commented about the resizability so I know it worked.

Looking at my Safari window that I'm typing this in, it's just three dark lines drawn over the brushed steel frame of the window. If you look really closely you can see that they also draw light lines to suggest depth, but they are almost invisible. It's very basic, and I don't think the lines are anti-aliased either.

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #12
MattDiamond Wrote:My game Black Cube showed the user that they could resize the window simply by drawing three white diagonal lines in the bottom corner. (The background was black for the entire window.) It didn't look awful, ...

You didn't read my entire post, did you Wink ?
Quote this message in a reply
Moderator
Posts: 434
Joined: 2002.09
Post: #13
PowerMacX Wrote:You didn't read my entire post, did you Wink ?

Nope, my bad. Somehow I went too fast over the middle bit. Sorry!

You and I basically agree, but my point was (in part) that it doesn't have to be a textured quad. I'd go with whichever way fits with the current code. If you already load and display some quad sprites then this is just one more. In my case I was already drawing some GL_LINE's so drawing three more in the corner was painless.

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #14
Lines won't look quite the same as the Aqua widget. Of course that might not matter to you.

If you want to closely approximate the Aqua widget, this will build a 16x16 texture for you (save 4k of disk):
Code:
// create resize texture
unsigned short* resize = calloc(1, 16*16*2);
unsigned short rszpix[] = { 0x0025, 0x128A, 0x748B, 0x0000 };
int x, y, i, j;
for (x = 4, y = 14; y >= 4; x++, y--) {
    for (j = 0, i = x; i < 15; i++) {
        resize[i+y*16] = rszpix[j];
        j++; if (j > 3) j = 0;
    }
}
glGenTextures(1, &rsztex);
glBindTexture(GL_TEXTURE_2D, rsztex);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE_ALPHA, 16, 16, 0,
    GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, resize);
free(resize);

It's still an approximation because the real widget has very (very) subtle variation across the largest line, but you can't really tell without comparing individual pixels in Photoshop.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #15
Awesome job arekkusu! Works like a charm. It's not quite perfect but I think it's actually better than the alpha blended quad coming straight out of the system prefs as you suggested earlier. It's great to have this hard-coded!
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  showing off new space game gooncorp 1 3,102 Nov 8, 2012 02:35 PM
Last Post: PythonBlue
  Nothing showing up in NSOpenGLView [newb] binaryinsomnia 6 6,294 Nov 29, 2011 07:04 PM
Last Post: binaryinsomnia
  Cocoa controls on top of NSOpenGLView wadesworld 5 5,799 Apr 6, 2009 01:38 AM
Last Post: arekkusu
  Antialiasing and NSOpenGLView attributes Jar445 2 6,464 Jan 20, 2009 10:42 AM
Last Post: maximile
  Adding NSOpenGLView class in Xcode/Interface Builder 3.0 Graphic Ace 2 3,664 Dec 5, 2007 02:15 PM
Last Post: Blacktiger