"Richard L. Peskin" <rlpcon at vermontel.net> wrote:
> Thanks Andreas--
>  Where do I find this specialized code? I have looked over the
> sqMacWindows.c and the only thing I see (other than window creation and
> event handling) is ioShowDisplay() which appears to do a PixMap to BitMap
> conversion, followed by a CopyBits(). Should I be looking elsewhere as well?

I think Tim and Andreas pretty much answered this question, but
just in case...

You can find the latest Win32 VM sources at:

    ftp.cs.uni-magdeburg.de
      /pub/Smalltalk/free/squeak

The sources are also be mirrored at

    squeak.cs.uiuc.edu
      /pub/Smalltalk/Squeak

The code you want is in the file sqWin32Windows.c.

For those folks interested in VM design issues, here are the
arguments in favor of the current Display design, which is to
have the Display object be a buffer owned by Squeak, as opposed to
a direct pointer to the hardware display buffer. (But note that
the latter design has also been explored in at least one Squeak port,
and required only a few modifications. Tim pointed out the hook
in the release VM to support it.)

  1. The current design is extremely portable.
  2. Keeping thes ame byte order is the on all platforms, allows folks to
     write very efficient platform-independent image processing code that
     doesn't need to take two byte orderings into account. This code can
     be translated into C to make it really fast. I've done some experiments
     with cross-fade primitives that were easy to build and really rip!
  3. Morphic uses the Squeak Display as an "offscreen buffer" to get smooth,
     double-buffered display updates. Give that one wants double-buffered
     display updates, the current design doesn't cost anything extra
     because you'd need an offscreen buffer anyhow.
  4. Copying pixels from the Squeak Display to the actual hardware display
     buffer takes, typically, well under ten percent of the overall display
     update time. Thus, having Squeak write into the hardware screen
     buffer directly could only speed things up a little, and that would be
     at the cost of portability and giving up double-buffering.
  5. There is definitely a cost associated with byte-reversal on little-endian
     machines. Yet the Andreas's in-place byte reversal is surprisingly
     fast, and that's the worst case. In many cases one can arrange to
     swap the bytes on the fly as the data is copied to the hardware
    display buffer, making the byte-reversal practically free.

I hope that you get to the bottom of the BeOS performance problem. Please
keep us posted.

	-- John