EditorStatus performance / UX

[lmihalkovic]

On Aqua progress bars are animated, which means the following code is called inside a rapid loop (~10x per second) whenever compilation happens

  public void paintComponent(Graphics screen) {
    Dimension size = getSize();
    if ((size.width != sizeW) || (size.height != sizeH)) {
      // component has been resized

      if ((size.width > imageW) || (size.height > imageH)) {
        // nix the image and recreate, it's too small
        offscreen = null;

      } else {
        // who cares, just resize
        sizeW = size.width;
        sizeH = size.height;
        setButtonBounds();
      }
    }

    if (offscreen == null) {
      sizeW = size.width;
      sizeH = size.height;
      setButtonBounds();
      imageW = sizeW;
      imageH = sizeH;
      offscreen = createImage(imageW, imageH);
    }

    Graphics graphics = offscreen.getGraphics();
    graphics.setColor(BGCOLOR[mode]);
    graphics.fillRect(0, 0, imageW, imageH);
    graphics.setColor(FGCOLOR[mode]);

    graphics.setFont(font); // needs to be set each time on osx
    int ascent = graphics.getFontMetrics().getAscent();
    assert message != null;
    graphics.drawString(message, Preferences.GUI_SMALL, (sizeH + ascent) / 2);

    screen.drawImage(offscreen, 0, 0, null);
  }

the interesting bit is the fact that there was the intention of saving some work by caching an offscreen image that gets painted to the screen... but the more interesting bit is that it is useless because the contents of the image is recreated each time anyhow.

this version on the other hand ensures that only the bliting of the image to the screen is done during the fast refresh loop. Then offscreen needs to be set to null in changeState().

    if (offscreen == null) {
      sizeW = size.width;
      sizeH = size.height;
      setButtonBounds();
      imageW = sizeW;
      imageH = sizeH;
      offscreen = createImage(imageW, imageH);

      Graphics graphics = offscreen.getGraphics();
      graphics.setColor(BGCOLOR[mode]);
      graphics.fillRect(0, 0, imageW, imageH);
      graphics.setColor(FGCOLOR[mode]);

      graphics.setFont(font); // needs to be set each time on osx
      int ascent = graphics.getFontMetrics().getAscent();
      assert message != null;
      graphics.drawString(message, Preferences.GUI_SMALL, (sizeH + ascent) / 2);
    } 

    screen.drawImage(offscreen, 0, 0, null);
}

this is just a piece of trivia. the code has been like that for 7 years, and I think it had more of an impact then than now (I fixed my local version anyhow)

The more interesting thought is that the progress is not really helpful to see what TOTAL work is going to happen: at the moment there are 2 hidden steps performed by the builder. Each one has its own sequence of ===progress xxxx / yyyy / zzzz to animate from 0 to 100%

From the viewpoint of the compiler this reflects what it is truly doing... but from the viewpoint of the user there is no way to predict anything, for all that matters I could be watching my UI and see the progress bar going from 0 to 100% 2 times (like it is the case now) or 1000 times, and in neither of these case would I have a clue if it will do it another 2000 times or if it will stop. To me this is bad user experience because it does not convey a user message, but a technical one, basically to the user there is no determinism (web browsers used to do the same, and report 0->100% for each individual file, but they switched long ago to a single estimated-time-to-usable-page feedback)

all that's required to make it deterministic from the user's perspective is that the compiler send something like a
===TotalSteps 2 or ===TotalSteps 2000
before it starts to bounce the progress bar around. Then the UI can show a single 0-->100 motion where each ===Progress xxx.yyy.zzz represents the relative work of task 1, 2, 3, ...
And KISS principle suggests that you should not add ===step:1 ===step:2... to the compiler because it is twice redundant.

[lmihalkovic]

Due to lack of interest