We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3394 - glFinish() required to share SDL_RENDERER_TARGETTEXTURE across contexts
Summary: glFinish() required to share SDL_RENDERER_TARGETTEXTURE across contexts
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: 2.0.4
Hardware: x86_64 Mac OS X 10.11
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-22 04:18 UTC by Jay Dolan
Modified: 2016-10-12 03:58 UTC (History)
2 users (show)

See Also:

Attachments
Brief example showing placement of necessary glFinish call (747 bytes, text/plain)
2016-07-22 04:18 UTC, Jay Dolan 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jay Dolan 2016-07-22 04:18:13 UTC 
Created attachment 2531 [details]
Brief example showing placement of necessary glFinish call

My application uses two OpenGL 2.1 contexts: one for 3D drawing, and a second for 2D drawing which uses the SDL_Renderer API. I'm using 2 contexts, because the SDL_Renderer API makes many GL state changes which are difficult to follow and reset -- so I thought it best to just give it its own context.

Therefore, my 2D rendering context uses a SDL_RENDERER_TARGETTEXTURE texture (ARB_GL_framebuffer_object_EXT). It draws its contents to the texture, and then I make the primary context active again, and blit that texture to the screen. This all works wonderfully. However, there was a snag that cost me quite a few hours. See attachment.

Apparently, before unlocking the texture and FBO, a call to glFinish is absolutely necessary (at least on OS X) to force the SDL_Renderer to completely render to the texture. Without calling glFinish, I was often left with a half-baked texture, a stale texture, or sometimes no texture at all!

Is this a known issue? Is it documented anywhere?
Comment 1 Alex Szpakowski 2016-10-01 20:26:45 UTC 
(In reply to Jay Dolan from comment #0)
> Is this a known issue? Is it documented anywhere?

Yes, it's how OpenGL works (you should probably use glFlush instead of glFinish though): https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_designstrategies/opengl_designstrategies.html#//apple_ref/doc/uid/TP40001987-CH2-SW15
Comment 2 Ryan C. Gordon 2016-10-11 17:35:43 UTC 
(In reply to Alex Szpakowski from comment #1)
> Yes, it's how OpenGL works (you should probably use glFlush instead of
> glFinish though):

So we should close this bug, right?

--ryan.
Comment 3 Jay Dolan 2016-10-11 18:03:11 UTC 
That's fine with me. I've moved away from this approach, in any case. I had just never encountered a real world scenario where glFinish() was actually useful / necessary. Seemed like a bug to me. But that's on me, I guess.
Comment 4 Ryan C. Gordon 2016-10-12 03:58:45 UTC 
(In reply to Jay Dolan from comment #3)
> That's fine with me. I've moved away from this approach, in any case. I had
> just never encountered a real world scenario where glFinish() was actually
> useful / necessary. Seemed like a bug to me. But that's on me, I guess.

Yeah, this always confused me.  :/

Closing the bug!

--ryan.