@Override
public void propertyChange(PropertyChangeEvent evt)
{
- // Respond to viewport change events (e.g. alignment panel was scrolled)
- // Both scrolling and resizing change viewport ranges: scrolling changes
- // both start and end points, but resize only changes end values.
- // Here we only want to fastpaint on a scroll, with resize using a normal
- // paint, so scroll events are identified as changes to the horizontal or
- // vertical start value.
switch (evt.getPropertyName())
{
case ViewportRanges.STARTRES:
case ViewportRanges.STARTRESANDSEQ:
case ViewportRanges.MOVE_VIEWPORT:
// scroll event, repaint panel
- // TODO: check this?
- // BH: This is actually quite strange. AlignmentPanel is taking care of
- // all of
- // this with fast paint, so why indirectly trigger a repaint from the
- // ScalePanel?
-
+ // original comment:
// Call repaint on alignment panel so that repaints from other alignment
// panel components can be aggregated. Otherwise performance of the
// overview
// window and others may be adversely affected.
- // av.getAlignPanel().repaint();
- System.out.println("ScalePanel propertyChange disabled "
- + evt.getPropertyName());
+
+ // TODO: check this?
+ // BH: This is actually quite strange. AlignmentPanel is taking care of
+ // all of this with fast paint, so why indirectly trigger a repaint from
+ // the ScalePanel? Where do we see this behavior necessary?
+ // I have set this to check for a trigger from some other ViewportRanges,
+ // but I don't actually think that is possible.
+
+ if (evt.getSource() != av.getRanges())
+ {
+ av.getAlignPanel().repaint();
+ }
break;
}
}