Package sim.display

Class Display2D.InnerDisplay2D

java.lang.Object
java.awt.Component
java.awt.Container
javax.swing.JComponent
sim.display.Display2D.InnerDisplay2D
All Implemented Interfaces:
ImageObserver, MenuContainer, Serializable
Enclosing class:
Display2D
public class Display2D.InnerDisplay2D extends JComponent
The object which actually does all the drawing. Perhaps we should move this out.
See Also:

  • Field Details

    • width

      public double width
      The width of the display when the scale is 1.0

    • height

      public double height
      The height of the display when the scale is 1.0

    • xOffset

      public double xOffset
      x offset

    • yOffset

      public double yOffset
      y offset

    • unbufferedHints

      public RenderingHints unbufferedHints
      Hints used to draw objects to the screen or to a buffer

    • bufferedHints

      public RenderingHints bufferedHints
      Hints used to draw the buffered image to the screen

    • lastToolTipEvent

      protected MouseEvent lastToolTipEvent

  • Method Details

    • removeListeners

      public void removeListeners()
      Deprecated.
      Use Display2D.removeListeners instead.

    • getPreferredSize

      public Dimension getPreferredSize()
      Overloaded to return (width * scale, height * scale)
      Overrides:
      getPreferredSize in class JComponent

    • getMinimumSize

      public Dimension getMinimumSize()
      Overloaded to return (width * scale, height * scale)
      Overrides:
      getMinimumSize in class JComponent

    • paintToMovie

      public void paintToMovie(Graphics g)
      Paints a movie, by drawing to a buffer, then encoding the buffer to disk, then optionally writing the buffer to the provided Graphics2D. If the Graphics2D is null, it's just written out to disk. This method will only write to disk when "appropriate", that is, if the current schedule has advanced to the point that a new frame is supposed to be outputted (given the frame rate of the movie). In any rate, it'll write to the Graphic2D if provided.

    • setupHints

      public void setupHints(boolean antialias, boolean niceAlphaInterpolation, boolean niceInterpolation)
      The default method for setting up the given hints. By default they suggest that Java2D emphasize efficiency over prettiness.

    • createToolTip

      public JToolTip createToolTip()
      Overrides:
      createToolTip in class JComponent

    • getToolTipText

      public String getToolTipText(MouseEvent event)
      Overrides:
      getToolTipText in class JComponent

    • updateToolTips

      public void updateToolTips()

    • createToolTipText

      public String createToolTipText(Rectangle2D.Double rect, GUIState simulation)

    • paintComponent

      public void paintComponent(Graphics g)
      Swing's equivalent of paint(Graphics g). Called by repaint(). In turn calls paintComponent(g,false); You should not call this method directly. Instead you probably want to call paintComponent(Graphics, buffer).
      Overrides:
      paintComponent in class JComponent

    • paintComponent

      public void paintComponent(Graphics g, boolean buffer)
      Deprecated.
      use paintComponent() or paint(...)
      The top-level repainting method. If we're writing to a movie, we do a paintToMovie (which also does a buffered paint to the screen) else we do an ordinary paint. buffer determines if we do our ordinary paints buffered or not.

    • paint

      public BufferedImage paint(Graphics graphics, boolean buffered, boolean shared)
      Paints an image to the screen either buffered or unbuffered. If buffered, the buffer is returned for your convenience. If SHARED is true, then the buffer is shared internally, so if you want to hold onto it without it changing, you'll need to make a copy. If SHARED is false, then the buffer is given to you to do as you like and a new buffer is created next time (less efficient). This method is called from Swing when the window is resized or scrolled or whatnot, but it's also called as a result of the underlying model thread advancing a step so we can see what happened. In the second case, the method could conceivably be called both from the Swing event thread (if making a movie, or if in MacOS X) or from the underlying model thread (if in Windows or X Windows -- to change this, see Display2D.step). This is important because this if we're being called from the Swing event thread (repaint/movie/MacOS X), we must ensure that we're not updating the model at the same time the model is changing, and to do that we lock on the simulation's schedule so we know the model is done with step() methods and nothing's moving. But because we're blocking on the schedule, a deadlock opportunity arises. For example, what if some foolish person writes a step() method in the model which calls some blocking item in the Swing event thread? Then they're blocking waiting for the Swing event thread to come available again, but the event thread is blocking because we're waiting for them to get out of the model. A similar problem could arise if in implementing a portrayal's draw method the user decides to call some blocking item in Swing, because this paint() method could conceivably be called from the model itself (in Windows/XWindows), and it's possible that at the very same time the user has pressed the stop button or done some operation in Swing which is blocking waiting for the schedule. Long story short, try not to call a blocking method on Swing from inside this method.