From: "Peter K. Stys" <[EMAIL PROTECTED]>
Date: Fri, 16 Feb 2007 16:24:01 -0500
On 2/16/07, Frank Condello <[EMAIL PROTECTED]> wrote:
On 16-Feb-07, at 3:16 PM, Peter K. Stys wrote:
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.
but if I pick a fixed endianness, the huge memblocks will always need
to be swapped on one of the platforms when the file is read.
That's why we are in this mess today. You do something wrong, and
then it gets embedded, and grows. Eventually everyone needs to do
everything forwards and backwards, despite that doing it forwards is
simpler and easier for everyone.
I'll bet initially it was just more convenient for Intel to do their
bytes backwards, due to some implementation quirk. By the time they
had their first release, it was too late to change despite that it
was no longer more convienient.
Anyhow that's just history.
If the
endianness matches the current platform, then the swap will only be
required if the file is opened on the other platform (a far less
frequent event).
Your logic is good, it will save the user time to have the file in
the format native to him. But then YOU must store a value in your
file to state which endianness the file is! Something like 01 for BE,
and 10 for LE.
This could break many plugin operations that perform direct byte-wise
access of pointers.
Good catch.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
