Hi Tim,

The Windows VM supports both big endian and little endian Display.  
This was done by Andreas and is supported in Cuis, see  
#setDisplayDepth. This essentially came from Squeak, so it's likely  
that Squeak can do the same.

On the Windows machines I tried, I could not see relevant performance  
improvements, and I guess this is because of Intel's instruction set  
and Andreas' performance tricks. But supporting this could be useful  
for RISC OS, right?

I remember in the old days of OS/2 Squeak, I added inline asssembly to  
use the fast intel asm op for byte reversing a 32 bit word...

Cheers,
Juan Vuletich

Quoting tim Rowledge <tim at rowledge.org>:

>
> On 06-02-2013, at 8:27 PM, "David T. Lewis" <lewis at mail.msen.com> wrote:
>>
>> Can you say which methods in Smalltalk (VMMaker) or functions in C are
>> consuming the 20% of processing? This sounds like something we should
>> profile on one or two other platforms but I'm not sure what to look for.
>
> It's very platform specific. Typically either ioShowDisplay or  
> ioForceDisplayUpdate actually does the work of moving pixels from  
> the object world to the glass. Squeak pixels are old Mac OS format -  
> big endian, a specific R,G,B & Alpha layout - and have to be  
> converted to the platform's needs. On RISC OS right now, each time  
> the ioShowDisplay code is called, the relevant pixels are converted  
> and copied to a shadow bitmap kept in RISC OS format; then when  
> display update events come from the OS, the accumulated damage areas  
> are copied from that to the glass. It takes roughly as long to  
> convert each area as it takes to update the screen (on my Pi, that  
> is. Some other RISC OS machines have faster memory busses or faster  
> graphics subsystems) and for flashing a largish area of the screen  
> that adds up fast.
>
> It's a long time ago and I don't recall very precisely, but I think  
> Andreas did some work on making bitblt to a platform bitmap work  
> much better under certain circumstances. IIRC it sort-of did the  
> right thing for RISC OS but failed horribly in some other way. I'll  
> need to take another look at that.
>
> Even longer ago I had code to make BitBLT work little-endian  
> entirely, and horribly abused the RISC OS graphics system to make it  
> think the Display bitmap object was actual screen buffer.
>
> Even longer ago than *that* I had a system that simply stole the  
> display hardware entirely. Wouldn't work with any other application  
> windows tough. Not so popular…. but bloody fast :-)
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: NNI: Neglect Next Instruction
>
>
>
>



Cheers,
Juan Vuletich