it is quite buggy. There are still issues with non-affine transformed
fonts, but they are lesser.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3456 542714f4-19e9-0310-aa3c-eee0fc999fb1
the scene block resolver on a new thread which could, in theory, then
request said colorizer before we got around to setting it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3455 542714f4-19e9-0310-aa3c-eee0fc999fb1
custom editors for simple data types. Added a checkbox editor for boolean
fields. Also switched the layout to the side as one is likely to
accumulate many objects and allowed an object to be specified as the
default.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3452 542714f4-19e9-0310-aa3c-eee0fc999fb1
now that all the scene updating stuff has been cleaned up. Basically we
can't rely on the updating process itself to assign a portal id, updates
must be created with all the information they need before they are applied
to the scene.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3451 542714f4-19e9-0310-aa3c-eee0fc999fb1
potential fuckola of being called before the controller gets around to
initializing the casted context it almost certainly needs to create its
place view.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3440 542714f4-19e9-0310-aa3c-eee0fc999fb1
needed all told, but I like to see the number keep going up.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3438 542714f4-19e9-0310-aa3c-eee0fc999fb1
methods they were looking for.
Since it's probably impossible to have proguard generically skip renaming
for these generated method names, let's update the fields in a different way.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3434 542714f4-19e9-0310-aa3c-eee0fc999fb1
that authentication is processed on the dobjmgr thread rather than
requiring the caller to do the right thing (or not as the case happened to
be).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3433 542714f4-19e9-0310-aa3c-eee0fc999fb1
be used by sprites and animations. Ray is now thinking, "Why do we have
this wacky difference between sprites and animations?" but changing it now
would be a massive amount of typing that I'm not super interested in
doing. In any case factoring out the "effects" into separate classes is
still useful because frequently one wants to combine them in crazy ways
that would not be possible with a FadeSprite or FadeAnimation.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3426 542714f4-19e9-0310-aa3c-eee0fc999fb1
different things in. Created FadeImage and FadeLabel derivations.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3425 542714f4-19e9-0310-aa3c-eee0fc999fb1
push-back buffer that prevents sounds from blarching when we reset the
stream.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3422 542714f4-19e9-0310-aa3c-eee0fc999fb1
implementations do a fucking DNS lookup on the host of the URL. The degree
to which that violates expectations about the "expense" of calling
hashCode() is so astronomical as to be unexpressible without complicated
metaphor.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3421 542714f4-19e9-0310-aa3c-eee0fc999fb1
condition between the omgr thread and the conmgr thread. Now when the omgr
thread processes an event that is going out to the clients, it flattents
the message itself for each client that is to receive the message and the
flattened data is posted to the conmgr outgoing queue.
This means that once an event is finished processing, no further
modifications to any of the data associated with the event can effect the
data queued up to be sent to the client. This is a good thing, it will
eliminate or illuminate a very baffling class of bugs that we've sort of
been ignoring because we knew this could be the cause.
We used to take an event and flatten it directly into the direct buffer
from which we would do our socket write. Now we flatten it into a
temporary byte array. This means a metric shitload more garbage generation
and collection. We used to do the flattening on the conmgr thread, now we
do it on the omgr thread. This means a big redistribution of CPU demand.
Either of those things could result in a significant negative impact on
our performance, but we'll just have to deploy this stuff and find out.
Whee! If it turns out to be a serious problem, there are potential
optimizations that could be done by keeping a pool of direct buffers
around and flattening messages into them, relying on the fact that the
outgoing conmgr queue generally doesn't grow too large and we could
allocate tens to a hundred megabytes of memory for the outgoing queue if
we really needed to.
I'd also like to test the overflow handling stuff more. It didn't really
change in that everything just deals with arrays of bytes now instead of
unflattened messages, but I'll be more comfortable once I've seen all this
in action on ice where there may be few users, but they are just as likely
to experience lag and receive an overflow queue as users on the higher
traffic servers. There is code to log when overflow queues are created and
finally flushed and how much use they got while they were around, so that
should give us an indication of whether things are operating properly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3419 542714f4-19e9-0310-aa3c-eee0fc999fb1
freaking out in standalone mode where the server is started, and shutdown
and started again repeatedly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3418 542714f4-19e9-0310-aa3c-eee0fc999fb1
whether or not we're already shutdown as it may have shutdown
unexpectedly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3415 542714f4-19e9-0310-aa3c-eee0fc999fb1
isometric rendering) and modified it to allow it to consider different
potential move sets than just moving by one in the eight cardinal
directions.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3411 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell