On Mar 25, 2004, at 11:40 AM, IOhannes m zmoelnig wrote:
and then i changed the code a bit to enable [gemhead]s to be created on the fly and immediately start rendering (without having to restart it manually by sending [0,1( to the [gemwin])
anyhow, this (and the prior changes to the GemCache) created a bunch of other mis-behaviour but i finally got an idea what made Gem crashing when objects where modified (e.g: sending floats to [rotate]) while rendering was turned off: all the objects hold local copies of the pointer to the GemCache. AND they modify the GemCache with setModified().
so i added a magic-number to the GemCache to ensure that the pointer is still valid. (and accordingly changed all the involved objects)
so i hope this issue is really fixed for now. any tests ?
This magically cured the random crash on OSX deep inside the OS window destruction routines. Why the hell this worked I have no clue.
The only thing I've found broken now is that stopping then starting rendering turns off all of the pix_ objects. I put m_processOnOff = 1; in the startRendering() in GemPixObj, but that didn't seem to work. I couldn't find any explicit setting of this beyond the constructor arguments anywhere else in GEM. Any ideas?
cgc
mfg.as.dra IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev