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