[Squeak32] Aparent Performance problems
martin at hand2mouse.com
Thu Apr 25 17:16:09 UTC 2002
At 11:46 AM -0400 4/25/02, Mike Shields wrote:
>I still don't know which endianness (big- or little-) to choose...
>I think it showed up in 3.2, but what is that talking about? Is it possible
>for the endianness of the video bytes to be different than the cpu? What
What I vaguely remember from discussions on the list quite a while
back is that Squeak's internal pixel format was always big-endian,
which slowed things down on little-endian systems due to the time
required to swap endianness during display updates, and that someone
added the option to make the internal endianness match the machine
endianness. This took some care to implement, as images saved on
little-endian machines must run on big-endian machines and vice versa.
I don't use the Windows version much, and the choices for endianness
don't show up on the Mac, (On Windows they appear on the display
depth menu) so I haven't really looked into this. However, when I was
deploying a very graphics-intensive application on 3.2g Windows
recently I tried both endiannesses, and found that the little-endian
choice actually slowed down my app somewhat.
This was for 32-bit depth, which did match the depth of the display.
Shallower depths may actually benefit from being little-endian. I
suspect that for 32-bit displays most things are handled by 32-bit
transfers for which endianness doesn't matter.
More information about the Squeak-dev