Width and Height are not initialised for gl read frame buffer in makecurrent

While running CTS on android we have seen glReadPixels produces 0x502 error i.e GL_INVALID_OPERATION.
We tried to analyse the code it returns invalid operation in read_pixels function.
This readpixels initially checks for the renderbuffer for a read operation exist or not. Actually this is a check for colorReadBuffer which was obtained as null.
The color read buffer pointer was updated to null as the parameters of the readbuffers width, height are obtained as 0. Im expecting these values to be updated to the surface width and height during make current but this was not happening. When navigated through the make current the width and height of surface ae not passed to point where read frame buffer is initialised, thus making it 0.

Can anyone please let me know if anything is missed here. Thanks in advance

Thanks,
Harinath

[QUOTE=Harinath;1293352]While running CTS [Conformance Test Suite] on android…

[ul]
[li]we have seen glReadPixels produces 0x502 error i.e GL_INVALID_OPERATION. [/li][li]We tried to analyse the code it returns invalid operation in read_pixels function. [/li][li]This readpixels initially checks for the renderbuffer for a read operation exist or not. [/li][li]Actually this is a check for colorReadBuffer which was obtained as null. [/li][li]The color read buffer pointer was updated to null as the parameters of the readbuffers width, height are obtained as 0. [/li][li]Im expecting these values to be updated to the surface width and height during make current but this was not happening. [/li][li]When navigated through the make current the width and height of surface ae not passed to point where read frame buffer is initialised, thus making it 0. [/li][/ul]
[/QUOTE]

It’s not at all clear what you’re talking about.

You are on Android, using OpenGL ES (and likely EGL), trying to do a glReadPixels, but it is returning GL_INVALID_OPERATION. That much is clear.

I think you’re saying that when the glReadPixels is performed, there is either 1) no bound, valid read framebuffer (GL_READ_FRAMEBUFFER_BINDING), or 2) no valid read buffer (GL_READ_BUFFER) within that framebuffer. Right?

And I think you’re saying that the reason this is true (#1 specifically) is because the last eglMakeCurrent() call bound no read surface, and the current GL_READ_FRAMEBUFFER_BINDING is 0. For instance via:


  glBindFramebuffer( GL_READ_FRAMEBUFFER, 0 );
  eglMakeCurrent( display, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT );
  ...
  glReadPixels( ... );

Right?

If so, what’s your question? It’s of course invalid to try to read from a buffer of a framebuffer which doesn’t exist and/or when there’s no active context.

Before doing the glReadPixels, you must bind a valid EGL context and bind a framebuffer containing the buffer you plan to read the pixels from.

Hi,

Thanks for the reply. Sorry that i was not clear.

There is a test application code which performs this glReadPixels operation where i get GL_INVALID_OPERATION

The code looks something like this

eglCreatePbufferSurface(…);
eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT );

glReadPixels( … );

I have uploaded the application code where glReadPixels is performed for reference.

There is nothing like glBindFramebuffer( GL_READ_FRAMEBUFFER, 0 ) before eglMakeCurrent as you mentioned in your sample code. I suspected that this eglMakeCurrent will do the necessary binding of EGL context with the read framebuffer. When i have seen the code of eglMakeCurrent, i found that eglMakeCurrent has some binding related functionality. I expected the width and height parameters of framebuffer to be initialized to surface width and height(in “_mesa_initialize_window_framebuffer”) during this call of eglMakeCurrent. However as i observed, the width and height parameters of gl framebuffer are not getting updated in “_mesa_initialize_window_framebuffer” but other parameters of gl framebuffer are getting updated. As this parameters of width and height of gl_framebuffer were not updated to surface width and height, this parameters remain 0 and that would result in a failure(like the one i observed).

Was my understanding wright?

If its correct, should there be a mechanism to update framebuffer width and height to surface width and height?

Thanks,
Harinath