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@30 corner: 50@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@128 depth: 32. 0 to: 127 do: [:y | 0 to: 127 do: [:x | t pixelValueAt: (x@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@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