Hallo!
I currently always get this message in Gem (each frame):
... separator : state->numTexCoords 4 != m_state.numTexCoords 0 separator : state->numTexCoords 4 != m_state.numTexCoords 0 separator : state->numTexCoords 4 != m_state.numTexCoords 0 ...
my patch looks like this:
| [separator] | [color] | [translateXYZ] | [scale] | [pix_buffer_read xxx] | [pix_texture] | [rectangle x y]
I can see in the source code of separator.h: --------8<---------- //this is a partial fix for the separator memory leak // //if the texcoords are of equal number, which they almost always are //then just copy them in a loop without delete and new being done // //when texcoords are not equal the memory leak happens as usual ------->8-----------
does this mean, in my patch there will be a memory leak (or is it just a debug post) ?
Thanks, LG Georg
[separator] needs to come after any pix_ objects to avoid the memory
leak. In your patch the saved state is before texturing is setup so
when the postrender is called the values are not equal.
On Aug 28, 2005, at 5:34 AM, Georg Holzmann wrote:
Hallo!
I currently always get this message in Gem (each frame):
... separator : state->numTexCoords 4 != m_state.numTexCoords 0 separator : state->numTexCoords 4 != m_state.numTexCoords 0 separator : state->numTexCoords 4 != m_state.numTexCoords 0 ...
my patch looks like this:
| [separator] | [color] | [translateXYZ] | [scale] | [pix_buffer_read xxx] | [pix_texture] | [rectangle x y]
I can see in the source code of separator.h: --------8<---------- //this is a partial fix for the separator memory leak // //if the texcoords are of equal number, which they almost always are //then just copy them in a loop without delete and new being done // //when texcoords are not equal the memory leak happens as usual ------->8-----------
does this mean, in my patch there will be a memory leak (or is it
just a debug post) ?Thanks, LG Georg
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list