Re: Refresh woes for custom OGL pane
Re: Refresh woes for custom OGL pane
- Subject: Re: Refresh woes for custom OGL pane
- From: Brent Gulanowski <email@hidden>
- Date: Tue, 30 Apr 2002 11:46:47 -0400
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.
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. 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??
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)?
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):
- (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.