GL_RED_SIZE etc. not reported correctly for FBOs with texture as color attachment

[GoogleCodeExporter]

With an active FBO that has a texture attached to the color attachment point, 
GL_RED_SIZE etc. all return 0.  This seems to be because 
Colorbuffer::getRedSize and friends touch mRenderBuffer directly, even if it 
may not have been set up yet by the getRenderBuffer that 
TextureColorbufferProxy overrides.

The attached patch fixes it, but it's not the most elegant, and has a whole 
pile of extra addrefs/gets/etc.  A better approach might be if (!mRenderBuffer) 
getRenderBuffer(); or something, but even that's pretty odd -- I don't 
understand the intended design fully to know where this should really go (maybe 
just in the constructor)?

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

Attachments:

• fb-size.patch

[GoogleCodeExporter]

Original comment by nicolas....@gmail.com on 1 Dec 2010 at 12:22

• Changed state: Started

[GoogleCodeExporter]

Thanks for reporting this. Your patch works but it's not fixing the underlying 
problem. Colorbuffer shouldn't call getRenderTarget() because it is a 
materialized renderbuffer (i.e. it derives from RenderbufferStorage). Indeed 
the renderbuffer parameters should all be set in the Colorbuffer constructors, 
both for render targets and textures.

Furthermore, Texture2D::getColorbuffer only creates a TextureColorbufferProxy 
when there was no previous one, but doesn't update it when the texture is 
rematerialized. This could cause the color depth to still be reported 
incorrectly, and I believe it's the cause of the incorrectly reported 
dimensions in Issue 52.

Fixing this may also require reworking the class hierarchy a bit and ensuring 
that the interfaces match the intended semantics...

Original comment by nicolas....@gmail.com on 1 Dec 2010 at 3:18

[GoogleCodeExporter]

Here's an updated patch.  This takes a different approach -- it bases the size 
queries etc. from the internal fields of the RenderbufferStorage, and updates 
those fields whenever a texture is redefined.  This actually simplified the 
code quite a bit; TextureColorbufferProxy doesn't need to override many 
methods, and it means that all fields of a RenderbufferStorage are valid for a 
TextureColorbufferProxy, where before some of the fields were bogus and had to 
be accessed through an accessor function.

The serial piece I think fixes issue 52, but I can't find my testcase for that; 
will need to recreate it.

Original comment by vladim...@gmail.com on 11 Jan 2011 at 10:02

Attachments:

• fb-size-fix.patch

[GoogleCodeExporter]

r553 should fix this issue.

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

[GoogleCodeExporter]

Original comment by nicolas....@gmail.com on 10 Feb 2011 at 3:44

• Changed state: Fixed