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