Fwd: Re: Window code issue

vuletich at ar.ibm.com vuletich at ar.ibm.com
Tue Dec 29 22:46:18 UTC 1998



Hello Trey, Dick & All

Trey said
> There are a total of three copies of the Squeak display:
> 1) Squeak's big-endian, internally allocated bitmap
> 2) The host system's intermediate bitmap, in the same pixel configuration
as
> the host display
> 3) The host display adapter (possibly a partial copy, if the Squeak
window
> is obscured in any way).
> Data flow is in one direction only, 1->2->3

In the OS/2 version of Squeak, the buffer 2) is in the same display depth
as Squeak. So this copy has only the endian conversion (This is not true
for 1, 2 and 4 bits of depth in Squeak, but these are easily expanded to 8
bits). The pixel depth conversion  in the 2->3 operation is done
automatically by this DIVE dll I told you about. It even does color
dithering if appropiate!
I didn't try to make it better, because the results are quite good (even in
my old 486). Try it, or try the Windows version, their performance is
similar (but turn off the 'Defer Display Update' in the Windows version for
realistic performance). Besides, I did not want to need a special image for
OS/2.

Anyway, It would be a big improvement to get Squeak write directly to 2).
In my particular implementation, besides needing Squeak to manage little
endian display formats, it is necessary to receive an external pointer
where the display buffer is allocated. (This is necessary to use hardware
acceleration). This is probably incompatible with the way Squeak manages
the memory for it's objects.

Regarding Tim Rowledge's work on little-endian BitBlt, I would only have
DisplayScreen in little-endian mode. Reversing all the forms in the image
seems to break the consistency across all platforms.

So we would need:
1) Little endian BitBlt, only when blitting to DisplayScreen
2) Have DisplayScreen memory outside the object memory
3) A primitive to automatically select the blitting endianess (Similar to
the way to handle the directory separator character)
4) Integrate all this stuff in the official Squeak release, to keep
complete portability.
5) Convince Andreas that the Windows version would also benefit from this.

If all this is possible, I will happily convert the OS/2 Squeak version to
this approach.

Juan Manuel Vuletich
SW Export  IGS- IBM Argentina
Phone Nbr : 54-1-313-0014 ext. 5207
Tie Line : 840-5207
e-mail: vuletich at ar.ibm.com





More information about the Squeak-dev mailing list