Diego,

> To Andreas: I think you are the best person to answer!

Yes, but what question? ;-) The one about endianness?!

Well, to put it briefly, the primary reason to have BitBlt be able to
deal with both forms was the integration of native drawing surfaces.
Since they're native you've got to be able to deal with the byte order
as given by the host OS. You can see this (for example) with the D3D
hardware acceleration - what we do is just grabbing the bits from the
VRAM surface and draw right into it (heh, heh).

Regarding speed: It depends. In many (actually most) cases staying with
MSB order will be just right. This is because doing a pixel-reversing
BitBlt (e.g., from LSB to MSB form or vice versa) is _expensive_. Thus,
if everything in your environment (forms, fonts etc) uses MSB
representation it makes a lot of sense to have Display be MSB too.
That's mostly since I have hand-optimized the pixel reversing operations
for Display since the very beginning of the VM and if there's a way of
making it faster then I just don't know it (consider this a challenge!
;)

In order to make a real comparison about speed you'd have to change
_all_ the existing forms to LSB and make _all_ form allocations be LSB
as well. This would give us equal grounds for comparison and then,
you'll see that something like "Display forceToScreen" which - in the
most interesting case of 16bpp - is about 30-50% faster as with MSB
makes a real difference. Right now, we're just trading the speed gain in
#forceToScreen against the loss in all those MSB-LSB blts.

So right now, this choice doesn't matter too much but if you have an app
where you redraw a lot of the screen and wish to optimize it a bit for
an LSB display there are always 10-20 msecs to get per frame.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Diego Gomez Deck
> Sent: Thursday, April 25, 2002 8:22 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: [Squeak32] Aparent Performance problems
> 
> 
> Hello..
> 
> >On Thursday 25 April 2002 08:46 am, 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?
> >
> >Where do you choose the endianness?
> >
> >I think that Diego is talking about the WorldMenu/appearance/set 
> >display depth setting, which provides the best speed generally when 
> >it is set to the depth of the native hardware.
> 
> Yes, I'm talking about this setting...
> 
> But in Windows the litte/big endian option is available... 
> anyway I found the "performance problem" when the bits x 
> pixel don't match with the windows setting. I din't find a 
> perceptible diference with little/big endian, anyway I have 
> not accurated measures but only "feelings.".
> 
> To Andreas: I think you are the best person to answer!
> 
> >-- 
> >Ned Konz
> >http://bike-nomad.com
> >GPG key ID: BEEA7EFE
> 
> Thanks,
> 
> Diego Gomez Deck
> 
>