Hi Robert, > I've done another review. What is the motivation by having the > ProxyLoadCallback have it's own FileName parameter as osg::Image > already has one. The load call can get the image and hence the > FileName from it. The only reason I can spot so far is that you are > using it in the compare method, but since you needn't do the compare > here, as you could move it in to the Image::compare() then you'd have > access to the required Image::getFileName().
Well, in the design I made, Images are supposed to be unloaded as well. Here is one of the motivating examples: - Load an image (let's say filename="aaa.tiff") - Modify the image - Rename the image so that the writers will change format and directory (ex: "foo/bar/bbb.jpg") - Let say we've reached our RAM limit during the load of another image. Loading the second image will unload the first one. What then? If we simply unload, we'll never be able to re-load the image as "aaa.tiff" filename would have been lost. Moreover, we'd lost the changes if we assume "aaa.tiff" corresponds to what's in memory (as the image has been modified). Should the unloading method write the image to "foo/bar/bbb.jpg" before freeing RAM then? I don't think so because: - It's maybe not the loader's job - If the filename refers to a lossy file format, we may have many load/unload/load/unload cycles and finally mess up the data. - The filename of the temporary image and the filename of the final image can be different (from a functionnality point of view). The temporary can point to a local drive while the final points to a remote drive. > My inclination is avoid > data duplication where possible. An advantage of making > ProxyLoadCallback stateless would be that you could attach on > callback > to many osg::Image. Yes, It would be nice. Actually I started dev without having a filename in the callback. If you got an idea that fits the unloading thing I described, you're welcome! I'd be happy to modify my implementation. > I've been pondering the issue of proxy images overnight and starting > to wonder if we shouldn't be tackling it in quite a different way. > Rather than lower integration with osg::Image via a callback I am > thinking that perhaps a Node update/cull callback that loads all the > proxy images for it's subgraph would be more appropriate. > > Such a callback could have a list of osg::Texture that need loading > and when traversal hits this node it could load them and then > continue > traversal of the subgraph or run the load in a back ground thread and > not do the traversal until that thread has loaded all the images. > This way you could load the sub graph and only have it appear on > screen once everything has loaded and make it possible to avoid frame > drops due to loading. One could still have the immediate load and > accept the frame drop, one could simply have a single callback with > two mods of operation or two different callbacks for each case. > > As well as enable constant frame rate support this callback approach > would keep all the required code localized in the callbacks, one > wouldn't need to modify osg::Texture/osg::Image. > > Thoughts? > Robert. That's a nice and far less intrusive way to do things. The idea of a constant frame rate support sounds very great to me. However, I use an "osgconv"-style app: it reads and then writes scenes, without rendering anything. I thus don't have any particular traversal, so I don't know how to do it with your idea. The goal of such an app (and osgconv too!?) is to be able to convert a scene with several GB of textures (in hundreds/thousands files). The way it works right now (with this Proxy image implementation) is roughly: - Load the scene without textures (textures are proxies) - Write the scene: if the texture name haven't changed (hence the requirement of two filenames!), simply copy the original file. Else load the image, write the loaded image with the appropriate writer, and unload the image. And just FYI, my app can load, write, and then use the loaded scene (still using proxy images). I hope my explanation is what you expected, and we'll find an implementation that fits most needs. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
