If we're freaked out enough that we're carping & ignoring it, I want to
be able to actually figure out what's broken.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@906 ed5b42cb-e716-0410-a449-f6a68f950b19
thing before committing instead of just going "oh yeah, I've been having this stuff
sitting around uncommitted for a while waiting on it to be blessed" and missing
out on things that'd changed in the meantime.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@665 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
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
Dave Hoover