April 2006


Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sean Luke <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Thu, 20 Apr 2006 19:45:16 -0400
text/plain (50 lines)
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
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

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