Sender: |
|
Date: |
Thu, 20 Apr 2006 18:38:42 -0400 |
MIME-version: |
1.0 (Apple Message framework v749.3) |
Reply-To: |
|
Content-type: |
text/plain; charset=US-ASCII; delsp=yes; format=flowed |
Subject: |
|
From: |
|
In-Reply-To: |
<161EB0F2DA2B6A44AF7C6FBF6C7842C617EAD2@CRA-EXCHANGE> |
Content-transfer-encoding: |
7bit |
Comments: |
|
Parts/Attachments: |
|
|
Marc, can you tell use what operating system you're using? It will
make a big difference here.
As to detatchAll() versus a specific portrayal: laziness. It's easy
for us to clean out everything, but detatching a specific portrayal
means shifting a bunch of stuff down. We figured one could detach
everything and then reattach the stuff you wanted. :-) :-) If it'd
be helpful for you, I could look into how to do it.
Sean
On Apr 20, 2006, at 10:48 AM, Marc Richards wrote:
>
> Forgive me if this a redundant post, I don't think my original
> message made
> it through to the list.
>
> I'm not getting the performance that I would expect out of the
> FastValueGridPortrayal2D with an immutable field. I've attached an
> example
> class that demonstrates the issue. The portrayal's field is a
> DoubleGrid2D
> that has random values between 0 and 1, mapped from translucent
> black to
> opaque black. Every 50 steps the values on the grid are reset to
> new random
> values. It seems to me that I should be able to get the best
> performance by
> calling setImmutable(true) on the portrayal, and calling reset()
> every 50
> steps. By "better performance" I mean the simulation steps faster.
>
> However, I don't have any noticable improvement if setImmutable is
> true or
> false. It doesn't seem to matter if the buffer is set to USE_BUFFER or
> DONT_USE_BUFFER. If the colors are mapped from opaque white to
> opaque black
> (so there is no transparency), performance is much better, but ONLY
> if I set
> immutable to false. Doesn't that seem backwards?
>
> 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.
>
> And a mostly unrelated question: Is there any reason you can
> detatchAll()
> from a Display2D but not detatch a specific portrayal?
>
> Thanks, and congrats on the new version,
> Marc
|
|
|