Hi, Jerome,

>>  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 far yes. I don't need to change the color mapping.
> Of course any particular color scheme is choosable. To
> the taste of the user. It is independent of the data.

  Good.  In my mental model, data is the stuff that changes
constantly, but "color map" is in the realm of "viewing" and changes
only now and then when the user wants to change it.

>>  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?
> 
> That's essentially what I decided to do with the power
> compressed data. Though I do it one pass behind to
> keep the min and max value data valid. This is the
> part of the design that is influx right now as I learn
> what works and reprogram to suit.  Gossamer Condor
> style.

  I don't know what Gossamer Conder style is, but sounds like we are
in some kind of agreement.

> >  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.  
> 
> In that case we could use a solid color pallete, color
> code the data and display it over the test area with
> an alpha blend.

  Ah ok, by looking at the picture, I thought you were doing alpha
blending on to Display, but sure yes, that wasn't the only way.

> What I am building is a probe to show where to speed
> optimize. And to test that speed optimization actually
> works. What I feared was that invalidating some parts
> of the screen would cascade to larger areas causing
> slowdowns.

  Hmm, so, a solution outside of invalidation and #drawOn: resime could be better?

> The picture shows this seems to be true when the
> invalid point overlaps the system window label. So
> probably caching the label bits will save a lot of
> grief. It also points to looking for speed
> optimizations in true font character display and maybe
> character display in general.
> 
> >
> >  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..."
> 
> pallette := (0 to: 255 )  collect: [ :each | Color
> black alpha: (each asFloat / 255 asFloat) .
> pallette := pallette reversed .
> ColorForm extent: (cols at rows) depth: 8 
>  ; colors: pallette .

  Yes, I actually tried this and it was where rendering onto 16-bit
depth didn't work.

  Thank you!

-- Yoshiki