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
>gives?

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.


-Martin