On Apr 20, 2006, at 10:48 AM, Marc Richards wrote:

> I feel like I must be missing something about how setImmutable  
> works. Any
> suggestions? I'm using WinXP with the most recent version of MASON.

Okay, dufus me, I didn't see the XP statement.  :-)

In short: I think what's happening is that we've optimized the  
FastValueGridPortrayal2D to the point where immutability doesn't buy  
you much.

The general idea of immutablity was to allow the system to optimize  
itself with the knowledge that you're rarely changing things.  For a  
FastValueGridPortrayal2D, this optimization takes the form of two  
optimizations:
	1. We can nudge the system to consider using a stretched buffered image
	2. If so, we don't bother to reassemble the buffered image; just use  
the preexisting one.

For #1: Probably not a big deal.  On Windows, using a stretched  
buffered image can actually hurt; but at any rate, Windows just draws  
it by drawing lots of rects.  On the Mac, a stretched buffered image  
is an enormous improvement; but it's used always anyway.  If you set  
USE_BUFFER, it'll be used regardless.  If you set DONT_USE_BUFFER,  
it'll never be used.  If you set DEFAULT, then on Windows it will be  
used if the field is immutable and not brand new.

For #2: used to be a much bigger deal, but now that we're writing  
directly into the low-level image map data, it's almost totally lost  
in the noise.

So where might immutability still be of value to you?  Mostly if your  
color mapping facility is something expensive, rather than using  
SimpleColorMap.

How about image buffering?  If I recall, it doesn't make a big  
difference in Windows, but in Linux, buffering is much faster if you  
have TONS of memory; otherwise, it's significantly slower.  You might  
try giving yourself lots of Java heap memory on XP too and see what  
happens just for fun.    Also, both buffering and rects are SLOW, if  
I recall, if you draw transparently.   But we don't have an option to  
force opaque images -- maybe we should, it'd be lots faster in  
Windows.  You might also try fooling around with  
FastValueGridPortrayal2D's image data organization (we use  
BufferedImage.TYPE_INT_ARGB, but on Windows maybe there's something  
faster?  Certainly an opaque image maybe?)

Sean