FBO-attached texture not resizing properly

[GoogleCodeExporter]

This might not be an actual problem, but I'm debugging something related, and 
I'm not sure if I'm seeing a possible bug here.  Code flow is (pseudocode):

  fb = CreateFramebuffer()
  tex = CreateTexture()

  BindTexture(tex)
  TexImage2D(tex, 200x200, NULL)

  BindFramebuffer(fb)
  FramebufferTexture2D(tex)

  // resize attached texture to 2x2
  TexImage2D(tex, 2x2, NULL)

at this point, if I examine 
((gl::Renderbuffer*)framebuffer->mColorbufferPointer.mObject)->mStorage the 
mWidth and mHeight fields there still say 200x200.  Inside a call like 
readPixels() though, the Direct3DSurface9's desc says 2x2, so that part is 
correct, but i'm not sure if that storage object should say the same thing.

The behaviour doesn't change if I call FramebufferTexture2D(tex) a second time 
after the resize (nor should it, afaik re-attaching should not be required)..

Original issue reported on code.google.com by vladim...@gmail.com on 2 Oct 2010 at 6:40

[GoogleCodeExporter]

Actually, this is a major problem -- all draws are going to the wrong 
destination, because of the check here: 

  http://code.google.com/p/angleproject/source/browse/trunk/src/libGLESv2/Context.cpp#1603

the serial was never updated when the render target was changed, thus drawing 
gets directed to the wrong place while reads still happen from the "correct" 
place, due to how readPixels is implemented.

Original comment by vladim...@gmail.com on 2 Oct 2010 at 6:54

[GoogleCodeExporter]

Here's a possible fix.. but I don't know if it does the right thing with the 
various lifecycles.  Seems to fix the problems I'm observing, though.

Original comment by vladim...@gmail.com on 3 Oct 2010 at 4:57

Attachments:

• fix.patch

[GoogleCodeExporter]

Original comment by kbr@chromium.org on 3 Oct 2010 at 10:25

[GoogleCodeExporter]

That patch seems correct to me. But in due time I'll have a closer look to 
maybe simplify this functionality a little and make the code more robust by 
improving the class hierarchy.

Original comment by nicolas....@gmail.com on 1 Dec 2010 at 4:10

[GoogleCodeExporter]

Original comment by nicolas....@gmail.com on 31 Jan 2011 at 3:55

• Changed state: Started

[GoogleCodeExporter]

Note that the updated patch in issue 51 fixes this as well, and is cleaner.

Original comment by vladim...@gmail.com on 31 Jan 2011 at 9:20

[GoogleCodeExporter]

I'm working on a solution which restructures the class hierarchy, to tackle 
this issue (and issue 51) at the root. You may expect a fix real soon now.

Original comment by nicolas....@gmail.com on 1 Feb 2011 at 11:15

[GoogleCodeExporter]

Sure; the fix in issue 51 is fairly clean though, in that it simplifies much of 
the current structure -- I'm curious why it isn't sufficient/appropriate.  But 
I'll take any kind of fix :-)

Original comment by vladim...@gmail.com on 1 Feb 2011 at 6:52

[GoogleCodeExporter]

r553 should fix both this and Issue 51.  I'll let Nicolas explain why/how :-)

Original comment by dan...@transgaming.com on 1 Feb 2011 at 6:57

[GoogleCodeExporter]

The issue was that TextureColorbufferProxy doesn't retrieve the texture 
properties (like dimensions) from the actual texture, but uses the member data 
which is only set during construction. Replacing the texture's colorbuffer 
proxy with a new one obviously fixes the issue, but a better solution was to 
let the TextureColorbufferProxy retrieve the current texture properties.

I then noticed that TextureColorbufferProxy is very similar to Colorbuffer 
itself, so I merged the functionality.

Original comment by nicolas....@gmail.com on 10 Feb 2011 at 4:14

• Changed state: Fixed