Unable to see best moves suggested from sgf (v0.7.4)

[bdrose]

When running an analysis, then saving the results, with "Hold best moves to sgf" enable, Lizzie is unable to display the best moves from the sgf. This appeared in Lizzie v0.7.4.
Lizzie v0.7.3 is able to open the sgf saved with v0.7.4 and correctly display the saved best moves.

[featurecat]

I've also encountered this issue. When I looked into the SGF file it is saving everything correctly, and this feature worked in 0.7.3. I think there's some kind of problem where the board's Komi and Engine Index is being stored incorrectly, either from the SGF or in Lizzie. When I temporarily remove the 2 lines...

lizzie/src/main/java/featurecat/lizzie/gui/BoardRenderer.java

Line 595 in ebeb446

&& Lizzie.board.getHistory().getGameInfo().getKomi() == Lizzie.board.getData().komi

So some time between 0.7.3 and 0.7.4 the komi / engine index storing got changed. @kaorahi do you have any ideas?

[NTUST-MITLAB]

The problem is Lizzie.board.getData().komi when the pondering is off, it only returns 0.0 komi from an empty BoardHistoryNode head. Any action either clicking on the variation tree node, click on the main board, or use arrow keys to advance to the next move/node doesn't set the head node with current komi information from the loaded game record.

It broke from this patch
ad63248#diff-c73f2e2e5ccbfe2cb930b22fab6b0f3735b7a8d77bfdbbbc502896c0fcb5b694

[NTUST-MITLAB]

While investigating this bug and try to get familiar with the structure of Lizzie, something odd occurred to me is the frequency this drawBranch() function got called.

When it is in pondering mode, it works fine for the most part, the mainboard calls it and the subboard calls it. And when a mouse moved to a candidate spot, it was called to draw.

But when a mouse just moves over the mainboard in the empty area while there are already quite a few candidate spots on the board, drawBranch() is called repeatedly along with any tiny mouse movement. Until it leaves the mainboard. I think there are some conditions not set quite right. The drawBranch() function shouldn't be called this often, or at least need to return when mouseover detects there is nothing to do earlier when there is nothing to do, and I suspect thin contribute to the lag we experienced navigating the variation tree.

[NTUST-MITLAB]

I put a stopwatch to monitor the values of these variables, and the value of isMainBoard keeps flipping between true and false when the mouse has a movement over the mainboard.

Check their values when this condition is matched by this.

  if (!suggestedMove.isPresent()
        || (!isMainBoard && Lizzie.frame.isAutoEstimating)
        || (isMainBoard && Lizzie.frame.isShowingPolicy)) {
      System.out.println(
          String.format(
              "suggestedMove.isPresent=%b isMainboard=%b isAutoEstimating=%b isShowingPolicy=%b",
              suggestedMove.isPresent(),
              isMainBoard,
              Lizzie.frame.isAutoEstimating,
              Lizzie.frame.isShowingPolicy));
      return;
    }

I think it has something to do with the subboard drawing frequency. When the mouse moves over mainboard it is still constantly being called. Maybe we should have an independent subboard render class that doesn't share the code with the mainboard rendering.