CCRenderTexture newCGImage not working

[rizerco]

There's currently an issue in:

[self begin];
[_renderer enqueueBlock:^
{
     glReadPixels(0,0,tx,ty,GL_RGBA,GL_UNSIGNED_BYTE, buffer);
} globalSortOrder:NSIntegerMax debugLabel:@"CCRenderTexture reading pixels for new image" threadSafe:NO];
[self end];

I think that because this now uses a block, that means that when this code actually gets executed is not known. So sometimes it works, sometimes it returns an empty image, and sometimes it throws an exception because a few lines later we call free(buffer) and buffer then gets modified after it is freed.

We could solve this by changing the syntax to include a completion handler, but I wasn't sure if the syntax should be changing? Alternatively the change that introduced this issue could be reverted, but presumably using the renderer is more efficient.

[slembcke]

Hmm. So there is one issue that I hadn't considered. Normally, begin creates a new renderer and end flushes it. So the block will be called before end exits. The exception is when you call it from within the visit or draw methods. In that case, there is already an active renderer and it enqueues it's drawing commands to that. In that case the end method does not flush the renderer. Is that what is happening here?

This was supposed to be an optimization, but I never really liked having the two separate code paths. Now that there is some code in place to pool CCRenderers instead of keeping a specific one around for the main rendering it should be easy to fix in later versions.

[Birkemose]

If we got rid of the blocks - like we talked about - wouldn’t that fix an issue like this?

On 18 Aug 2014, at 16:45, Scott Lembcke notifications@github.com wrote:

Hmm. So there is one issue that I hadn't considered. Normally, begin creates a new renderer and end flushes it. So the block will be called before end exits. The exception is when you call it from within the visit or draw methods. In that case, there is already an active renderer and it enqueues it's drawing commands to that. In that case the end method does not flush the renderer. Is that what is happening here?

This was supposed to be an optimization, but I never really liked having the two separate code paths. Now that there is some code in place to pool CCRenderers instead of keeping a specific one around for the main rendering it should be easy to fix in later versions.

—
Reply to this email directly or view it on GitHub.

[slembcke]

Not in this case no. The GL code in the newCGImage method is not in a draw method and must be explicitly wrapped.

[Birkemose]

Ahhh, of course not. My bad.

On 18 Aug 2014, at 16:58, Scott Lembcke notifications@github.com wrote:

Not in this case no. The GL code in the newCGImage method is not in a draw method and must be explicitly wrapped.

—
Reply to this email directly or view it on GitHub.

[slembcke]

This should be fixed in 3.3. Need to verify though.