Queue.append() only does a notify() if the queue was previously empty.
So when the dobj thread was requesting two sounds one after another, it
only woke up one player thread, which played the first sound and then
came back 'round to play the next sound after it was done. The next sound
was usually expired by that time.
Use queue.appendLoud(), which always wakes up a waiter thread.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3342 542714f4-19e9-0310-aa3c-eee0fc999fb1
getting dropped because they're taking too long to play. Extended the
max delay to 1000ms, which will surely help more sounds play, but may
not be worth it. Hey, we've got a test server to test on...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3337 542714f4-19e9-0310-aa3c-eee0fc999fb1
has been changed, except the names to protect the innocent.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3316 542714f4-19e9-0310-aa3c-eee0fc999fb1
rectangle of the area that would have been copied, as we know that the
_entire_ visible area is now dirty due to the failed copy. Replace the
list of dirty rectangles with one rectangle encompassing everything, it will
cut down on the iterations in the paint() method and should improve
performance on the JVM that exhibits the copyArea bug.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3307 542714f4-19e9-0310-aa3c-eee0fc999fb1
The SoundManager used to keep the AudioSystem's Line open for up to 30
seconds after a sound was played, maybe because I thought that opening
the line was expensive, or because it makes an audible 'tick' in linux
if no other sounds are playing. Well, it turns out that the sound looping
bug is the result of some internal befuckery of Sun's caused by keeping
the line open. Restructed the sound manager so that lines are opened
every time a sound is to be played and then closed immediately after.
This also allowed me to simplify a thing or two, and sounds should actually
be more responsive, in a tiny way, since previously the dobj thread asked
to play a sound, the sound manager thread would load the clip data and
finally a data spooling thread would play the actual sound. Now there is
no sound manager thread- so the dobj thread adds a sound to the queue and
one of the playing threads wakes up, reads the data and plays the sound.
Factored out all the music stuff into a new MusicManager. There was almost
nothing shared between the two, and it was just annoying to have one
monolithic manager that had all the logic and variables for both of these
distinct functions. The music manager also no longer has a processing
queue, everything takes place on the dobj thread.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3303 542714f4-19e9-0310-aa3c-eee0fc999fb1
There is no more SafeInterval, instead Intervals can be constructed with a RunQueue to use for expiring.
PresentsDObjectMgr implements RunQueue.
Client has a getRunQueue() method to get the client side RunQueue.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3283 542714f4-19e9-0310-aa3c-eee0fc999fb1
and just dirtying the entire panel, we don't want to set _dx and _dy, as
that will trigger the actual use of copyArea and so forth during painting.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3232 542714f4-19e9-0310-aa3c-eee0fc999fb1
constructor to reflect that rather than requiring coordinates that are
then not really valid.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3214 542714f4-19e9-0310-aa3c-eee0fc999fb1
potentially scrolling view. Also added a means for non-sprites and
animations to hear about view scrolls.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3209 542714f4-19e9-0310-aa3c-eee0fc999fb1
in the front layer which is generally what we want.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3190 542714f4-19e9-0310-aa3c-eee0fc999fb1
return a tile with an error image so that the caller doesn't freak out and
we achieve maximal "continue to work as much as possible."
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3177 542714f4-19e9-0310-aa3c-eee0fc999fb1
1. Modified the performance metric code to use hundred microseconds rather
than milliseconds as millis are not sufficiently fine grained.
2. Switched from using an ObserverList to a hand-rolled mechanism for
frame participants. It is unfortunate that we're not reusing code (though
this turns out to be 55 fewer lines of code) but the FrameManager needs to
allow tick participants to be removed from the list while in the middle of
processing another participant's tick.
With the ObserverList we have to use SAFE_IN_ORDER_NOTIFY which adds
undesirable overhead to each tick, or FAST_UNSAFE_NOTIFY which is
efficient, but freaks out if an as-yet-unticked participant is removed
during another particpant's tick.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3140 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell