On Fri, Feb 3, 2012 at 3:12 PM, Robert Osfield <[email protected]> wrote: > Normally for binary support I would suggest putting an endian marker > into the file and then reading this to determine if the file is big or > little endian then decide whether to swap depending on the system > reading the file. As the file format is already out there adding this > is not ideal as it'd break the format so I think it reasonable to > assume that all binary .osga files will be little endian. Performance > wise I do rather the ability to choose which endian the data will be > written out as so one can make sure it's optimal for the target > hardware.
I'd seen that the ive format did an endian test to determine which format the file was written out in. But there is no endian flag field in the current osgb file format. We could use the OSG_HEADER_LOW/HIGH fields, testing for swapped versions, but I didn't like that as it means there are two "magic number" variants at the start of the file. I far as I know most other binary file format (such as image file formats) just choose an endian value and lump it on other systems. Thats why I just went for little endian, its the most common for x86 and ARM, as you say. Actually my model tool path tends to generate the models on a big endian system, but deploy on x86 - so choosing little endian is better for me than writing the file in the generating system format. > > One thing I'm less comfortable with is > removing the optimization of reading an array and then doing the byte > swap. For reading binary files performance is crucial and it's the > large arrays, such as geometry and images that consume most of the > space, these we don't want to have to byte swap at a low level, or > even check for the need for byte swapping. Reading of images is not affected, as they are read as byte arrays and its up to the image format plugins to then sort out endian matters. Reading a vertex array as a single io would be good, but it seemed a lot less clean doing most of the byte swap handling in the BinaryInputOperator, and some in InputStream. There would have to be linkage set up to let InputStream know what was required. And its not actually just byte swapping, there's the issue of different sizes on 64-bit machines which I addressed in BinaryInputOperator::readLong(). I also assumed that as the input is derived from std:istream its all buffered anyway, so we're not going to be doing lots of little i/o. Perhaps a read array method could be added to the InputOperator classes. Your call of course. Regards Colin McDonald _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
