Le 24 nov. 08 à 11:35, WT a écrit :
>>[...]
>>Is this the right idea? Does anyone have a better suggestion? Are
>>there any pitfalls that I'm not seeing? One concern I have is that
>>there might be some weird interactions between running the
simulation
>>and drawing the results due to the fact that the simulation engine
is
>>running on a timer and the drawing engine is running on another
timer,
>>and their periods might not be commensurate.
>
>As long as the refresh rate of your simulation is high enough and
the frame rate is high enough, you should not notice any anomalies
due to the differences between the two. You are right that there
will be theoretical unevenness in the rendering, but with everything
happening fast enough, a human isn't going to notice.
Very true. Another of my concerns, though, is that having high
enough simulation refresh rates and frame update rates will cause a
large number of object allocations, which will compete with other
resources needed for the simulation to happen. It seems to me that
lots of objects in Cocoa cannot be reused once created and have to
be created again.
For instance, as far as I know, there is no way to change the period
of an NSTimer that's already in existence. Since both the simulation
update rate and the frame update rate are timer-driven and
dynamically changeable by the user, I expect lots of NSTimer objects
to be created.
I think you can reuse it using -[NSTimer setFireDate:] to set the next
fire date. The doc is not very clear about it. If this is not the
case, you can use CFRunLoopTimerSetNextFireDate (as NSTimer and
CFRunLoopTimer are tool free bridged), which has a better documentation:
"Resetting a timer’s next firing time is a relatively expensive
operation and should not be done if it can be avoided; letting timers
autorepeat is more efficient. In some cases, however, manually-
adjusted, repeating timers are useful. For example, if you have an
action that will be performed multiple times in the future, but at
irregular time intervals, it would be very expensive to create, add to
run loop modes, and then destroy a timer for each firing event.
Instead, you can create a repeating timer with an initial firing time
in the distant future (or the initial firing time) and a very large
repeat interval—on the order of decades or more—and add it to all the
necessary run loop modes. Then, when you know when the timer should
fire next, you reset the firing time with
CFRunLoopTimerSetNextFireDate, perhaps from the timer’s own callback
function. This technique effectively produces a reusable, asynchronous
timer."
>[...]
>Mike starts with the constraint "when multithreading for the
purposes of optimization", and taken at face value I don't see
anything wrong with the paragraph per se. But...
>
>There's "optimization", and then there's "optimization". :) I have
the impression from your original message that this isn't so much
about improving throughput as it is about keeping the user-interface
from being dependent on the simulation rate, thus improving the user
experience.
>[...]
Precisely!
>Also, not directly related to Mike's comment, but I'll point out
that multithreading can be a _design_ optimization as well. That is,
while it will necessarily introduce some complexities into the
implementation, it can also greatly simplify other aspects, by
allowing the various work in the program to be partitioned more
completely. So, there are often benefits to implementing
multithreaded code, even if performance will not be improved one bit.
Very true, and it's certainly the case in my application.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
