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
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
render sprites and animations over the top of everything in the frame:
JComponents, MediaPanels anything we like. To support this, we have the
MediaOverlay tell the ActiveRepaintManager when it has dirtied an area of the
screen and it will mark that component as needing repainting. Peachy.
However, if a component decides on its own that it needs repainting, we need to
propagate that now dirty region up to the MediaOverlay so that it can repaint
anything that's above the just-repainted component on the same frame tick.
This also fixes a potential problem if a changed sprite dirties a component
which then repaints itself but the bounds of that component overlapped some
other sprite which was not going to be repainted on this tick.
There were also potential problems if components were put in the JLayeredPane
layers (which are "above" the normal components and MediaPanels but "below" the
MediaOverlay). They too should now properly dirty regions in the overlay.
It occurs to me though that if a MediaOverlay sprite is on top of a MediaPanel,
the MediaPanel will probably not properly propagate its dirty region to the
overlay because the MediaPanel is a frame participant, not a JComponent and its
repainting is handled by the FrameManager not the ActiveRepaintManager. I may
just use the sledgehammer approach and dirty in the media overlay the entire
bounds of a frame participant if it paints anything on a frame rather than try
to translated and propagate its underlying dirty regions up to the overlay.
Oh the twisty maze of passages we've created in trying to create an active
rendering system that works magically with Swing.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@566 ed5b42cb-e716-0410-a449-f6a68f950b19
inaccurate System.currentTimeMillis() timer. Fortuately Sun introduced
System.nanoTime() in 1.5 which provides civilized timing information, so we can
use that instead of sun.misc.Perf which is unavailable in an applet sandbox. We
will need to go in and try to cope as best we can with currentTimeMillis() if
we want to support unsigned play in JDK 1.4 or earlier. We'll do that later.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@231 ed5b42cb-e716-0410-a449-f6a68f950b19
to have to think about), but it's totally untested. That comes next!
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@115 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
Mike Thomas