JAL-3253-applet JAL-3383
[jalview.git] / src / jalview / gui / ScalePanel.java
index aa58a88..b06647d 100755 (executable)
@@ -569,31 +569,29 @@ public class ScalePanel extends JPanel
   @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;
     }
   }