It will work on every Intel Mac ever made.
GL_MAX is an ancient feature from GL1.4; you have to go back about ten years to find a computer that it won’t work on.
It will work on iOS, too (but more slowly than using gl_LastFragData.)
What other bugs you see ?
Lots. First, let’s look at your original code to understand why it doesn’t work:
glBlitFramebufferEXT(...)
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, _krSecondFramebuffer);
...
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, self.bounds.size.width, self.bounds.size.height, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0);
...
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, _krTexture, 0);
In this sequence, you’ve just blit from _krFramebuffer to _krSecondFramebuffer, and then you’re immediately re-allocating a new _krTexture and attaching it to _krSecondFramebuffer. So the contents of _krSecondFramebuffer are effectively undefined junk when you sample. This sequence doesn’t make any sense.
Let’s first review the concept of what the framebuffer is.
It looks like you’re porting a GLPaint app from iOS to OSX. On iOS, you’re using a single EAGL framebuffer, and I’m assuming that you’re drawing a new quad each frame at the finger position, and accumulating all of the results into the single framebuffer over time. On iOS, this works by using kEAGLDrawablePropertyRetainedBacking. That EAGL framebuffer has a special “presentable” renderbuffer attached to it. By default, when you call -presentRenderbuffer: its contents become undefined (because, for performance reasons, the OS is maintaining a double- or triple-buffered queue behind your back.) kEAGLDrawablePropertyRetainedBacking changes the behavior so that it works more like a single buffer you can keep drawing into forever (but behind your back maybe it is copying the contents every time you present.)
On OSX, the equivalent is a window with an NSOpenGLView. In the pixel format, you can either make it single-buffered, or you can use NSOpenGLPFABackingStore to mimic iOS.
In either case, this “system drawable” is a special thing different from other FBOs; you can’t texture from it (well… on OSX you can, with [NSOpenGLContext createTexture:fromView:internalFormat:] but let’s ignore that.)
Keeping the closest equivalent to the iOS setup, the sequence should be something like:
- Create window, using NSOpenGLPFABackingStore to match EAGLDrawablePropertyRetainedBacking. This is “FBO zero” that will accumulate all drawing over time.
- Create one previousTexture, attach it to previousFBO. Initially clear it.
each frame:
- render this frame’s new finger quad to window, with shader using custom blending, sampling from previousTexture
- blit (composited window result) to previousFBO to use next frame (you can optimize the blit to just the area around the quad.)
You really don’t want to re-TexImage every frame, you only need to do that when the framebuffer changes size. You also only need to call glViewport when the size actually changes.
I’m discussing the basic framebuffer concept here, because in your later code you’re creating multiple framebuffers and renderbuffers, and it looks very confused.
Another option would be to create two FBOs, with two textures, and ping-pong between them every frame. In that sort of setup, the window does not need NSOpenGLPFABackingStore. This is different than what you’re doing in iOS, but is a common pattern in more complicated apps (i.e. games) that need a post-processing pass and render to texture anyway.
Let’s look at some other little misunderstandings:
CGSize size = self.bounds.size;
This will be in points, not in pixels. It won’t properly support a retina display.
GLuint loc = glGetUniformLocation(_programHandle, "previousTexture");
glUseProgram(_programHandle);
glUniform1i(loc, 0);
This is redundant. Uniforms are initialized to zero at link time.
If you were going to use a different unit, you should do this setup during init, not each frame.
gl_PointSize = 1.0;
This has no effect in desktop GL unless you glEnable(GL_PROGRAM_POINT_SIZE).
Unlike ES, desktop GL defaults to context-state glPointSize(). And this is all meaningless unless you’re actually drawing points.
glBindFramebuffer(GL_FRAMEBUFFER, 0); // this seems to be required before binding to read and write to different buffers
Certainly not required.
glBindFramebuffer(GL_READ_FRAMEBUFFER, _krFramebuffer);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, _krSecondFramebuffer);
glReadBuffer(GL_COLOR_ATTACHMENT0);
GLenum buffers[] = {GL_COLOR_ATTACHMENT0,};
glDrawBuffers(1, buffers);
This is all redundant too. Read and Draw buffer state is tracked per-framebuffer. And it defaults to GL_COLOR_ATTACHMENT0 when you create an FBO.
(Basically, unless you use MRT you never need to call glRead/DrawBuffer.)
Finally, let’s directly answer the original question. First, make sure you carefully understand what EXT_shader_framebuffer_fetch actually does:
- gl_LastFragData exposes the current framebuffer value as a fragment shader input. This happens per fragment. So if you draw two overlapping triangles, they are shaded in order: for the first triangle, gl_LastFragData sees i.e. the clear color. For the second triangle, gl_LastFragData sees the first triangle. You could shade millions of (potentially overlapping) triangles in a single draw call, and they would all be composited correctly, in order, with your custom blend equation.
This functionality relies on the TBDR architecture of iOS devices, and does not have any direct replacement on desktop GL. There are some options to approximate it:
- ARB_shader_image_load_store (GL4.2+) lets you read and write from arbitrary texels. If you render to a texture, you could manually implement blending. This is the closest replacement, but it’s not available on OSX (even if it was, it would only work on recent GL4-capable Macs, so you’d still need another solution for the millions of older Macs.)
- NV_texture_barrier lets you sample from the same texture you are currently rendering to, but you have to manually flush writes before reads. So it doesn’t handle overlapping triangles in a single draw call-- you have to manually split overlap into separate draws. (On the upside, you’re not limited to reading only the current pixel; you can read neighboring texels too.) This is available everywhere in 10.9 Mavericks.
- Manually copy to a texture (via glBlitframebuffer, or glCopyTexImage) and sample from it. This is what you’ve attempted. Obviously, you can only copy what you’ve drawn, so you can decide to copy once per frame, or per overlapping triangle. This is available everywhere.
So for a completely general replacement, there isn’t an easy answer; handing the overlapping case is complicated.
Your specific use case (assuming there is only one finger drawing at a time, so there is no chance of overlapping triangles in a single draw call) seems simple enough that NV_texture_barrier can work; however you have to be rendering to a texture, not the system drawable. Copying data to a texture can also work. But really I think the simplest answer (and closest to iOS-- no extra framebuffers) is to render each quad in two passes like I said in the previous reply.
