Gerrit Voss wrote: > 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. > I'm using 1.x, so that was my plan. :)
Cheers, /Marcus ------------------------------------------------------------------------- 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
