Displaying data on screen was (How can I get from an array... to a bitmap).

Displaying data on screen
was
How can I get from an array,, to a bitmap.

***
>Yoshiki Ohshima yoshiki at vpri.org
>Wed Feb 6 01:13:28 UTC 2008
>
>
>
>  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.

Correct.

>> >  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?

See explaination below.

>
>> 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, rendering onto 16-bit
>depth didn't work.
>

Ok. A challenge but not a great difficulty. What I am
doing is:

 I have a thumbnail of the dataForm in an area away
from the test area.  I found I liked a behavior where
moving the mouse onto the thumbnail pops the full
sized morph over the test area. So you can do the
transparency by jiggling the mouse . You can even get
the full form to blink if you place the thumbnail so
that the full morph pops over it. (I discovered the
popup interupted the mouse enter event and generated a
mouse leave :-) No mouse moving necessary.

So a solid pallette would still give plenty of clues,
easily seen.
I'm set to try:

huePallette
^ ( Color red wheel: 3 * 128 ) first: 256
 
Which I think will go from red to blue, 2/3 of the
spectrum. But it will be easier to check than to
figure it out first. And then adjust the code till it
does what I want.

For documentation purposes I just open a stay up copy
of the popup morph. For 16 bits you would modify that
so the copy is half the data colors and half the
drawing behind it.

Yours in curiosity and service, --Jerome Peace





      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page.
http://www.yahoo.com/r/hs