Hi Jerome,

  Oh, that picture looks interesting.  If the values you're getting is
valid, that is a fun tool.

> >  This description is very vague, I have to say.
> 
> Ah, and here I was thinking I was being precise
> without going into unnecessary detail. :-/

  Now, why don't you have to post the code there? ^^;

> >  - What are the number of columns and rows?  What
> are inside?
> The columns and rows are settable by the user. Once
> set they are knowable.
> As for the inside on one end it is data about time and
> on the other just a colorful way of displaying the
> contrast amoung the data.

  These values are somehow [0..255], right?  If you use Bitmap or
ByteArray instead of Array, that would be easier.

> >> The application I have will essentially update the
> >> array over time and I wish to display it visually.
> I
> >> would like to do it in a time efficient way rather
> >> than pixel by pixel.
> >> 
> >> I've looked at the options in the image and I am
> not
> >> sure which ones are right.
> >> 
> >> Ideally once the color form is set up I should be
> able
> >> to update it just by updating the bitmap from the
> >> array periodically.

  As I understand, the values in an Array (now it would be in a Bitmap
or a ByteArray) change over time, and you want to map the values to
colors.  Isn't the mapping static?  I.e., it doesn't change over time
so that the same value in data is always mapped to the same color?
So, I could build a color map (a Bitmap object) once, store it
somewhere like in a class variable and use it?

> I eventually realized I did not have to set the bits
> all once and what worked was building a pixel poker to
> my form.

  Hmm.  In this approach, is it possible to bypass the step of storing
data into the Array and read from it?  I.e., just (effectively) write
into the bits of the ColorForm by using the pixel poker?

> By holding on to the poker I can update the form fast
> enough. The appllication is scanning the display for
> slow spots and will generate one datum per several
> cycles. 
> I collect the data as integers into an array and it
> was ok to store a pixel each time the data came in.
> 
> This was simple and it worked (after I found a bug or
> two in my typing.) And this lets BitBlt continue to
> hide the difficulties with endianness and so forth.
> 
> Still a fast way to go from array to bitmap would be
> useful.
> Its not to hard to insist the columns be a multiple of
> 4 so the data keeps word boundrys intact.

  I don't know how you scan and acquire data, but I'd imagine that you
get a value for a rectangle that is the bounding box of a morph.  If
so, you can "fill" the bitmap with an expression like:

aForm fill: (30 at 30 corner: 50 at 50) fillColor: (Bitmap with: 128).

(i.e., a Bitmap of length 1 can be used in place of a Color.)

  By the way, using ColorForm with translucency fails when the
destination (or Display) is 16-bit depth.  (And, I found out that
there are particular combinations of depth and translucency and kind
of morph you use that don't work either in Etoys image or 3.9.  Hmm.)

  Given that, it is safe to go with a 32-bit form:

	t := Form extent: 128 at 128 depth: 32.
	0 to: 127 do: [:y |
		0 to: 127 do: [:x |
			t pixelValueAt: (x at y) put: (x bitShift: 24)]].
"Gradient Fill with some trick can do above better, but to illustrate the idea..."

And, 

	(SketchMorph new form: t) openInWorld.
	"which doesn't work in the 3.9 image in 16-bit Display depth."

or better write the following in your morph's #drawOn: method:

	t displayOn: Display at: 100 at 100 rule: 34.
	"this works in 16-bit display or 32-bit display (and 8-bit^^;)"

  Well, I learned a lot about the differences between 3.9 and Etoys
image in this exercise.

  To do the #bitShift: above efficiently for a rectangle of data, you
could do the trick with #hackBit and WarpBlt together (like the way in
SugarLibrary).  But this would be another round...

-- Yoshiki