On Nov 18, 2009, at 4:50 PM, Nima Talebi wrote:
Issue Part I
Hmmm, no I haven't removed any such code, mainly because it doesn't exist in the Heatbugs app (and I haven't modified the framework)...
Okay, then probably the best thing to do is run one of the performance tools, I think its ObjectAlloc. That will give you an idea of what objects are being allocated and growing.
Issue Part II
Regarding threads - What I found is that drawing the heatspace is quite time consuming, so I wanted to processing to just continue on one processor, while the other one, in the background (and on another core), updates the slow-to-compute heatspace display.
The better way to do this is don't update the GUI display so often, so in HeatbugsGUI change the display frequency from 1 (which means to update the GUI every single time step) to some larger number like 10.
obj->displayFrequency = 1;
But you may have missed my main point from the earlier email, you cannot let the simulation continue, while at the same time trying to "probe or query" the simulation (from another thread) to update a display, because the simulation may change its state in the middle of the "query". In the minimal case, your display is just updated with wrong simulation state info. In the worst case, your display attempts to access simulation objects that no longer exist, thus causing an exception.
But as you said a few days ago, if it's not dangerous to call [self swarmHasUpdatedNotification] unless exactly one run of a `[heatSpaceDisplay updateDisplay]' AND one run of a following `[heatbugDisplay updateDisplay]' is already executed, then I can't really thread.
I'm not sure I understand your paraphrase, why the emphasis on AND? dangerous to call?
If the comments in the -updateGraphicalDisplays method don't make any sense, then maybe they need more elaboration so that they do make sense. They make perfect sense to me, but then I wrote them ;-)
Scott