Closed GoogleCodeExporter closed 9 years ago
Original comment by nicolas....@gmail.com
on 1 Dec 2010 at 12:22
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
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:
r553 should fix this issue.
Original comment by dan...@transgaming.com
on 1 Feb 2011 at 6:56
Original comment by nicolas....@gmail.com
on 10 Feb 2011 at 3:44
Original issue reported on code.google.com by
vladim...@gmail.com
on 2 Oct 2010 at 6:34Attachments: