there will be relatively few of those (at most one per client that is
experiencing lag) and while the client is experiencing lag we will be
trying to write their data once per pass through the sockets (which could
be hundreds of times a second) and we don't want each write attempt to
result in the creation of a temporary direct buffer.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3345 542714f4-19e9-0310-aa3c-eee0fc999fb1
another instance of append() that needed to be changed to appendLoud().
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3343 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
flattens messages into a buffer and then passes that bucket to a
SocketChannel.write() method which is part of the NIO business. If said
buffer is a "direct" buffer, the write() method will in theory do
high-performance shit like DMA the data right to the network card. If it's
not a direct buffer, Sun apparently makes a temporary direct buffer,
copies the data into it and passes that on to the underlying socket send()
call. We weren't using direct buffers which means that we were copying
everything one more time than needed (not a huge deal) and that we were
allocating a direct buffer for every message (a much bigger deal). This
should take a serious load off of the I/O thread and fortunately we can
test it on Ice to make sure it doesn't do anything super crazy.
All this said, this whole business is going to change when I rearchitect
Presents to avoid the potential race conditions it suffers from now and we
won't be able to use a single direct buffer to write all of our outgoing
messages, but I believe we will be able to use a pool of direct buffers
with one used by every message in the queue waiting to be written
(hopefully that won't be too many at any given time) which we can keep
around to avoid the expense of allocating and freeing direct buffers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3336 542714f4-19e9-0310-aa3c-eee0fc999fb1
sufficiently incompatible with GNU make that I'd rather just have two
whole separate goddamned directories with their own Makefile than try
to get everyone to agree on how to do things.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3328 542714f4-19e9-0310-aa3c-eee0fc999fb1
the throes of a previous connection. Also don't spuriously recreate our
ticker because it's very possible for logon() to be called and not
logoff(), logon() might fail, for example.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3321 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
changed the output format to be the same as the one for DObjectManager
profiling output.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3309 542714f4-19e9-0310-aa3c-eee0fc999fb1
actually dispatching the event to subscribers. We can't trust anyone.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3308 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
Michael Bayne