Hi, On Thu, 2007-08-16 at 17:25 +0800, Gerrit Voss wrote: > Hi, > > On Thu, 2007-08-16 at 11:15 +0200, Marcus Lindblom wrote: > > Dirk Reiners wrote: > > > Hi Marcus, > > > > > > Marcus Lindblom wrote: > > > > > >> > > > > I also tried doing it myself, using an MFTextureChunk field as > > attachment, but I couldn't get the attachment to work as I wanted. I > > failed to retrieve the attachment, even though I basically copied the > > SimpleNameAttachment line for line. > > > > I could try to use the Parents field instead. That'd definitely be easier. > > kind of, if you can take the 2.x image and texobjchunk as a reference > you will note that the changed interface was modified in order to choose > the right update method for the texture. In 1.x you most likely have to > force a reload the whole texture. I guess this was the main reason not > to automatically invalidate the texture as the image was changed. > > Ideally this change should go back into 1.x. Otherwise people who rely > on the image not forcing a reload of the texture chunk will > experience a performance drop. Especially if the work with > TextureChunk::imageContentChanged.
on a second thought the easier 1.x solution would be instead of calling the generic TextureChunk::changed you could downcast the parent and in case it really is a texture chunk invalidate it correctly depending on what of the image actually changed. kind regards, gerrit ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
