Re: Refresh woes for custom OGL pane
Re: Refresh woes for custom OGL pane
- Subject: Re: Refresh woes for custom OGL pane
- From: "Erik M. Buck" <email@hidden>
- Date: Tue, 30 Apr 2002 13:15:46 -0500
----- Original Message -----
From: "Brent Gulanowski" <email@hidden>
>
>
On Tuesday, April 30, 2002, at 10:29 AM, Erik M. Buck wrote:
>
>
>
> If you call - drawRect: yourself, the contract that the receiver "can
>
> assume
>
> the focus has been locked, drawing will be clipped to its frame
rectangle,
>
> and the coordinate transformations of its frame and bounds rectangles
have
>
> been applied" is invalid.
>
>
How does this affect OpenGL drawing? I make OpenGL drawing calls in a
>
totally separate method (from -drawRect:), and I've got no issues with
>
clipping.
If you are using OpenGL full screen, you do not have to worry about Cocoa at
all. If you are using subclasses of NSOpenGLView in windows then don't
abuse the frameworks. Don't do things behind the framework's back or you
will have problems. If you are unwilling to live within the architecture of
the frameworks then don't use them. Don't pretend to use them and then do
everything in ways that are contrary to their design.
When OpenGL is used in a window, the window server process and its
compositor must copy the pixels rendered with GL back to main memory in
order to place the pixels within the window accounting for overlapping
windows, drop shadows, etc. All of that is coordinated by Cocoa's -display
methods.
>
>
> Furthermore, -displayRect: does even more: it
>
> causes views below transparent views to be redrawn, coordinates backing
>
> store buffer flushes, and cleans up the graphics context
after -drawRect:
>
> .
>
> This is particularly important for subclasses of NSOpenGLView!
>
> -displayRect:
>
> configures the GL context and manages buffer copies between main memory
>
> and
>
> VRAM. If you bypass -displayRect: by calling -drawRect: directly, you
are
>
> abusing the frameworks and will almost certainly cause problems
including
>
> the reported problem of not having a valid GL context within -drawRect:.
>
>
Currently OpenGL contexts do not support transparency.
Yes they do. Press the keyboard buttons to change the volume while a OpenGL
view is in the center of the screen. Notice the transparency effects.
Transparent windows including the drop shadows are composited on top of GL
views by the window server.
>
How much overhead
>
are we accruing by worrying about it, especially if we're redrawing thirty
>
or more times a second? And when are we accessing main memory? OpenGL is
>
talking to the rendering pipeline on the graphics card, no??
When you are using OpenGL full screen, you do not need to use main memory.
When you are using OpenGL in a window, the window server must copy the
rendered pixels out of VRAM into main memory to apply transparency, drop
shadows, overlapping windows, etc. Using -display correctly tells the
window server how to do these things most efficiently.
>
>
> Displaying an NSView centers around the drawRect: method, which
transmits
>
> drawing instructions to the Window Server.
>
>
What if the only thing you've got in -drawRect: is OpenGL code? Who is
>
sending instructions to the Window Server? Are you also implying that
>
calling OpenGL without doing the full redisplay is problematic (say, if
>
you're calling OpenGL drawing routines from another method, like I do)?
The Window Server owns the entire frame buffer and a second buffer. When
not full screen, nothing gets to the frame buffer without the consent of the
Window Server. Full redisplay is not the issue. You can use displayRect: to
display just a portion of a view that draws with GL. The issue is that
NOTHING happens to the screen without the Window Server's involvement when
not full screen. Furthermore, the Window Server is double buffered and
tries to schedule buffer swaps on v-blanks... Doing things behind Cocoa's
back prevents Cocoa from telling the Window Server what is going on and
possibly prevents Window Sever optimizations such as coalesced buffer
flushes, v-blank synchronization, etc. I don't know how much practical
impact this has, but it is an issue.
>
>
Also, by deliberately calling [self openGLContext] in -initWithFrame:, I
>
can get my OpenGL setup code out of the way and avoid the annoying kludge
>
(visible in many of Apple's NSOpenGLView samples) or checking for the
>
first call to -drawRect: to do it, like this (from GLApp.pbproj):
Do what you want. I don't care. If you can get something working, I say
more power to you. I think you are doing it the hard way. I think you are
doing more work than necessary. I think you are preventing Window Server
optimizations. I think you are inviting redraw oddities involving Cocoa and
the view hierarchy. I think that if you have weird display problems they
will be impossible to debug. Good luck.
>
>
- (void) drawRect: (NSRect) rect
>
{
>
if (processFunc)
>
{
>
[self performSelector: processFunc];
>
processFunc = nil;
>
}
>
...
>
>
I do this:
>
>
// MyOpenGLView.m
>
#import "MyOpenGLView.h"
>
>
@implementation MyOpenGLView
>
>
-(id)initWithFrame:(NSRect)frameRect {
>
>
[ super initWithFrame: frameRect pixelFormat: [NSOpenGLView
>
defaultPixelFormat]];
>
[ self openGLContext ];
>
>
// initialize OpenGL environment here //
>
>
return self;
>
}
>
>
-(void)awakeFromNib {
>
theWorld = [[MyWorld alloc] init];
>
}
>
>
-(void)drawRect:(NSRect)frameRect {
>
>
// reset the viewframe in response to resize //
>
}
>
@end
>
-----
>
// MyWorld.m
>
#import "MyWorld.h"
>
>
@implementation MyWorld
>
>
-(id)init {
>
[super init];
>
[self update];
>
return self;
>
}
>
>
// update the state of the world to effect animations
>
-(void)update {
>
>
/*openGL transformation and drawing here*/
>
>
[self performSelector:_cmd withObject: nil afterDelay: 0.05f];
>
}
>
>
----
>
>
Is this going to lead to the same problems? And what are they, as opposed
>
to "abusing the frameworks"?
>
>
Brent
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.