On 16-Feb-07, at 3:16 PM, Peter K. Stys wrote:
On 2/16/07, Charles Yeomans <[EMAIL PROTECTED]> wrote:
The best thing would be to be able to pick a representation, say,
little endian, and use it always. If you have control over reading
and writing of image data, then you should be to do so.
Charles:
this would be easiest, but I suspect not best: if i used say
littleEndian always, then my app running on a bigEndian Mac would
always be forced to either byte-swap a 100 MB file during read/write,
or worse, force the memblocks to byte-swap every m.ushort access
because m would be set to its unnatural littleEndian setting on a
bigEndian machine. Or am I missing something?
The overhead of calling ushort is in the function call itself - if
you swap the whole block as Theo suggested you're actually doing
_more_ work. i.e. Calling bytevalue 4 times is way slower than
setting littleendian and calling ushort once. The littleendian
property is just a flag that's checked in every (applicable) accessor
whether the swap happens or not - there's nothing inherently slow
about it.
Now, I would still swap the whole block in this situation (or at
least the parts that need it) but do it using Ptr.Byte not
Memoryblock.ByteValue and you'll see a massive gain. Honestly though,
for large blocks like you're describing I'd do this sort of thing in
a plugin, which will be faster still. Once your block is swapped for
the current platform you can use fast Ptr access all the time without
worrying about endianess. You still need to pick an endianess and
stick to it for the file format however.
Frank.
<http://developer.chaoticbox.com/>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
