Closed GoogleCodeExporter closed 9 years ago
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
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:
Original comment by kbr@chromium.org
on 3 Oct 2010 at 10:25
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
Original comment by nicolas....@gmail.com
on 31 Jan 2011 at 3:55
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
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
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
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
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
Original issue reported on code.google.com by
vladim...@gmail.com
on 2 Oct 2010 at 6:40