copyCGLContextForPixelFormat
-
CAOpenGLLayer has a copyCGLContextForPixelFormat: method which the
documentation states "allocates a new context with a null share
context".
So we make a new context based on the supplied pixel format. So why
does this method contain the word "copy"?
Regards,
Richard -
On Feb 2, 2008, at 2:25 PM, Richard Somers wrote:
> CAOpenGLLayer has a copyCGLContextForPixelFormat: method which the
> documentation states "allocates a new context with a null share
> context".
>
> So we make a new context based on the supplied pixel format. So why
> does this method contain the word "copy"?
This method is for subclasses to override, only the CAOpenGLLayer
class should ever to call it (same for the other three similarly named
methods). The normal reason you'd want to override this is to return a
context sharing with another GL context you'd previous created. If you
override one of the -copyCGLBlah methods you should override the
related -releaseCGLBlah method to clean up whatever objects you created.
We could have called it -retainCGLContextForPixelFormat: but that
might imply you could return the same context for multiple layers at
once. "copy" implies a lack of sharing, which is how this normally
works.
John -
On Feb 2, 2008, at 4:17PM, John Harper wrote:
> This method is for subclasses to override, only the CAOpenGLLayer
> class should ever to call it (same for the other three similarly
> named methods). The normal reason you'd want to override this is to
> return a context sharing with another GL context you'd previous
> created. If you override one of the -copyCGLBlah methods you should
> override the related -releaseCGLBlah method to clean up whatever
> objects you created.
>
> We could have called it -retainCGLContextForPixelFormat: but that
> might imply you could return the same context for multiple layers at
> once. "copy" implies a lack of sharing, which is how this normally
> works.
John, thanks for the reply. Perhaps you could give me some further
suggestions. I have the following view structure.
Primary opengl graphics view
Secondary opengl overlay view
Secondary quartz overlay view
I thought I would try layer-backed views to accomplish this hierarchy.
The first problem I ran into was the opengl layer-backed context. I
start with a double-buffered NSOpenGLView subclass for the primary
view. Then when I switch the view to layer-backed and the new context
is not double-buffered. I have observed this loss of opengl double-
buffering in my own code and also in Apple's LayerBackedOpenGLView
sample code.
So the next thing I thought I would try is to forgo the automatic
layer-backed context creation and try to create a layer-backed double-
buffered context manually.
Any thoughts?
Richard -
On Feb 2, 2008, at 7:47 PM, Richard Somers wrote:
> I thought I would try layer-backed views to accomplish this
> hierarchy. The first problem I ran into was the opengl layer-backed
> context. I start with a double-buffered NSOpenGLView subclass for
> the primary view. Then when I switch the view to layer-backed and
> the new context is not double-buffered. I have observed this loss of
> opengl double-buffering in my own code and also in Apple's
> LayerBackedOpenGLView sample code.
>
> So the next thing I thought I would try is to forgo the automatic
> layer-backed context creation and try to create a layer-backed
> double-buffered context manually.
>
> Any thoughts?
Not really, it sounds like what you're describing should work. If you
use CAOpenGLLayer (either directly or via NSView) you don't need to
use double buffering, that is already taken care of (via a different
mechanism)
John -
On Feb 3, 2008, at 10:37AM, John Harper wrote:
> Not really, it sounds like what you're describing should work. If
> you use CAOpenGLLayer (either directly or via NSView) you don't need
> to use double buffering, that is already taken care of (via a
> different mechanism)
I have a very simple test application with a single subclassed
NSOpenGLView view. On an older machine with an ATI Radeon graphic card
(machine meets the official Leopard requirements) the frame rate drops
from 88 fps to 34 fps when switching to layer-backed mode. When I try
Apple's LayerBackedOpenGLView sample code application the same thing
happens, the frame rate drops from from 60 fps to 25 fps when
switching to layer-backed mode.
I noticed with both of these applications that when switching to layer-
backed mode the pixel format was changed from double-buffered to
single-buffered so I thought that might have something to do with the
slow down. But apparently from John's comment this is how Core
Animation is supposed to work.
Now I try the same test on a newer machine with an Intel GMA 950
graphics card. With my very simple test application the frame rate
remains constant at 60 fps when switching to layer-backed mode. With
Apple's LayerBackedOpenGLView sample code application the frame rate
actually increases from 35 fps to 45 fps when switching to layer-
backed mode.
So here is my question. Is there something inherently inconsistent
with the current implementation of a layer-backed OpenGL view that
will cause a slow down in frame rates when used with some graphics
cards or is this a known issue that is being addressed?
Regards,
Richard -
On Feb 4, 2008, at 5:24 AM, Richard Somers wrote:
> I noticed with both of these applications that when switching to
> layer-backed mode the pixel format was changed from double-buffered
> to single-buffered so I thought that might have something to do with
> the slow down. But apparently from John's comment this is how Core
> Animation is supposed to work.
CA manages the multiple buffers itself, so each one is single buffered
from OpenGL's point of view.
> So here is my question. Is there something inherently inconsistent
> with the current implementation of a layer-backed OpenGL view that
> will cause a slow down in frame rates when used with some graphics
> cards or is this a known issue that is being addressed?
Not that I know of, though I am only familiar with the CA side of
things. Probably the best thing is to file a bug report including the
sample app showing the problem,
John -
On Feb 4, 2008, at 10:53AM, John Harper wrote:
> Not that I know of, though I am only familiar with the CA side of
> things. Probably the best thing is to file a bug report including
> the sample app showing the problem,
Bug report filed. Problem ID: 5723351
Regards,
Richard Somers
