Since its dirty regions propagate out to the repaint manager, a big update
there would lead to dirty calls ping-ponging back and forth for a few cycles.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@600 ed5b42cb-e716-0410-a449-f6a68f950b19
saver that is Eclipse's "Infer generic types" which leaves HashMap and
ArrayList as the declared type where I would normally prefer to change those to
Map and List and use Maps and Lists to instantiate them.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@593 ed5b42cb-e716-0410-a449-f6a68f950b19
unneeded imports.
I've got partially completed patches for narya & vilya, too, but nenya was the
only one that wound up in a decent state after a friday evening puttering at it,
killing time waiting on other things to finish.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@572 ed5b42cb-e716-0410-a449-f6a68f950b19
naturalOrder() which allows media to use a more consistent "same render order"
order resolution value than Object.hashCode().
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@248 ed5b42cb-e716-0410-a449-f6a68f950b19
Sprite/AnimationManager -> AbstractMediaManager.
A smidgen more progress on MediaOverlay, but we need to get these bits checked
in ASAP.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@114 ed5b42cb-e716-0410-a449-f6a68f950b19
render sprites and animations anywhere in the frame for those times when you
just need to draw outside the lines.
The actual MediaOverlay isn't done yet, but all the refactoring to support it
is done, so the rest should be easy. In theory this shouldn't break anything
(like the Yohoho build), but we're about to find out.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@112 ed5b42cb-e716-0410-a449-f6a68f950b19
I'd really prefer to put this in the sprite package, but putting it here means I don't have to publicize the willStart/willFinish/didFinish functions on Animation. I'm open to suggestions for better solutions to that one...
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@96 ed5b42cb-e716-0410-a449-f6a68f950b19
things properly if they do. Simply stealing our target sprite's _bounds will
not result in the necessary calls to addDirtyRegion() if they change due to
calls to setLocation() on our (now unmanaged) target sprite.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@89 ed5b42cb-e716-0410-a449-f6a68f950b19
and efficiently dirty old and new bounds when our bounds change.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@88 ed5b42cb-e716-0410-a449-f6a68f950b19
Dave Hoover