Hi Jeremy and Robert, In fact the osg::Image class can be derived and it is possible to write serializers for the subclasses. In osgWrappers/serializers/osg/ImageStream.cpp you will find an example which has no difference from other serializers. I'm not sure if this could work for osgCairo images, but I think a subclass that doesn't change osg::Image's basic functionalities can work fine with serializers at present.
After reviewing the source code, I think it also possible to replace the readImage() and writeImage() in Input/OutputStream classes with an Image serializer, too. I can't remember why I use special reader/writer functions to handle images. Maybe it is only a plagiarism of old osgDB::Input/Output class' methods. :-P Cheers, Wang Rui 2011/8/17 Jeremy Moles <[email protected]>: > Hello everyone; this is probably a question only a few people could > possibly, answer (Robert, Wang), but here goes: > > I have created a derived osg::Image class (osgCairo::Image), and this > has worked just fine for the last few years. However, I want to add > strong serialization support for my nodekits, and I'm finding > customizing an Images behavior in the serialization code is quite > difficult. > > Images are treated as special kinds of Objects, so any custom behavior > you might add confuses the base serializers, and there doesn't appear to > be any way to avoid this. > > My question is: should the serialization backend be modified to support > osg::Image subclasses, or should programmers be encouraged NOT to derive > from osg::Image directly and instead create "contains-a" objects > instead? > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
