[Newbies] Bitmap loading from array - representation

[johnps11 at bigpond.com]

>
> On Dec 1, 2007, at 20:34 , Pete wrote:
>
>> Hi, I'm new to Smalltalk, coming from C++ and Java.
>>
>> I find Squeak very interesting, especially the
>> features for rapid prototyping.
>>
>> I tried learning on the job, started with the
>> Games-Chess class category, as I'm was formerly
>> experienced in chess programming.
>>
>> My problem is that I dont understand how Bitmaps for
>> Forms are defined:
>>
>> blackKingImage
>> 	^((Color yxForm
>> 	extent: 40 at 40
>> 	depth: 2
>> 	fromArray: #( 0 0 0 0 0 0 0 0 0 0 4194304 0 0
>> 22020096 0 0 4194304 0 0 89391104 0 0 111411200 0
>> 1398016 107216981 1426063360 22369600 107218261
>> 1430257664 22456660 107222362 2772434944 89740885
>> 111416741 1498415104 90527125 1162892885 1448083456
>> 93672805 1095850325 1448083456 362108249 1431656790
>> 2522087424 362190169 1435854230 2522087424 362190422
>> 1452643686 2522087424 362112598 1431672169 1448345600
>> 362112597 2505463146 2522087424 93760085 2505463145
>> 1448083456 93678165 2526434665 1448083456 93673045
>> 1704351141 1498415104 90527317 1700353429 1498415104
>> 23418261 1700353429 1497366528 22631829 1499027029
>> 1497366528 22631829 1503221333 1698693120 5657957
>> 1503222101 1694498816 1463653 1499026773 2483027968
>> 1414485 1499026774 1409286144 354986 2841291433
>> 1342177280 87381 1431655765 1073741824 21845
>> 1431655765 0 5802 2863311508 0 6485 1431655780 0 6485
>> 1521046884 0 6485 1431655780 0 6826 2863311524 0 5461
>> 1431655764 0 0 0 0 0 0 0)
>> 	offset: 0 at 0)
>> 	colorsFromArray: #(#( ) #(0.0 0.0 0.032) #(1.0 1.0
>> 1.0) #( )  ))
>>
>> I searched the whole Web for an explanation, but found
>> none.  It's also not clear to me why this array is
>> size of 120, when we have an rectangular region of
>> 40x40, and what is the difference of depth 1,2,4 ...
>
>
> Depth is the number of bits per pixel. Depth 2 means 2 bits per
> pixel, hence 4 colors.
>
> The array stores 32 bits per element. So at depth 2 you get 16 pixels
> per element. You need 3 elements per row for 40 pixels. 40 rows times
> 3 words per row is 120. Mystery solved.
>
> FYI, pixels are stored big-endian by default.
>
> And I'm pretty sure Form even has a class comment, as should Bitmap.
>
> - Bert -

Although Bert's answer is probably obvious to someone familiar with
Smalltalk, since Pete is "new to Smalltalk, coming from C++ and Java" an
answer not designed to embarrass him and send him running back to Java and
Smalltalk is:

If you search for "fromArray:" using "selectors containing it" from the
"more" menu you'll find

Form>>extent: extentPoint depth: bitsPerPixel fromArray: anArray offset:
offsetPoint
	"Answer an instance of me with a pixmap of the given depth initialized
from anArray."

	^ (self extent: extentPoint depth: bitsPerPixel)
		offset: offsetPoint;
		initFromArray: anArray

and if you then do the same for "initFromArray:" you'll find

Form>>initFromArray: array
	"Fill the bitmap from array.  If the array is shorter,
	then cycle around in its contents until the bitmap is filled."
| ax aSize array32 i j word16 |
	ax _ 0.
	aSize _ array size.
	aSize > bits size ifTrue:
		["backward compatibility with old 16-bit bitmaps and their forms"
code that seems to be a maze of twisty little bitShifts, all alike, follows.

It appears that the reason the bitmap is in an array of 3840 bits that is
used to store an image requiring 3200 bits has something to do with the 30
year heritage of Smalltalk.

I have to admit that Bert's explanation has me none the wiser - the leap
from 2 16 bit words per element (16 pixels) meaning that 3 elements (96
bits, 48 pixels) equals 40 pixels, which is 3 words per row seems a little
unclear (as 48 != 40 in most sane algebras).  Does this mean that in this
case the low-endian word of every third element is just padding, and has
no meaning for the bitmap?  I _think_ that's what it means, but the code
in Form>>initFromArray seems a little opaque to me, and I can understand
that other "Newbies" than just myself would find it a little confusing.

John