Xboard sluggish on OSX

[JoshPettus]

yah sorry it was from linegap

[hgm]

Well, that was my mistake. I added 1 pixel to the square size where I should have added lineGap, but as I was testing with LineGap = 1, everything seemed to work. I just pushed a fix that should work for any gap width.

There are so many things that a rewrite like this could break that I don't dare to think about it. So any testing you could do would be more than welcome. How it works with arrow on/off, marking target squares on/of, highlight last move on/off, drag-drop or click-click moving or moves by engines, linegap 0, 1 or larger, animate moving on/off... In all combinations. Not to mention 2-leg moves, taking back moves with <, replaying them with >... And not to forget flashing the piece, which in GTK so far was completely broken. And how that behaves with castling, and promotion (through drag-drop or click-click, and through a popup or sweepSelection). To judge the quality of the animation it helps to set it slow (e.g. to 200 instead of 10).

And I still have to fix WinBoard, where the arrow now slowly rolls out from underneath the animated piece rather than being exposed when drawn. And in 2-leg moves the piece re-appears on the from-square after the first leg, so that during the second leg there are two of them...

[hgm]

Hmm, apparently WinBoard has never exposed the arrow at the time it was drawn, and relied on the animated piece moving along it to expose it. I never noticed this, at normal animation speed. Apparently no one else did either, as I never eceived any complaints about it. So I guess I will leave it that way.

Move animation in XBoard is also a bit flaky: very often I only see part of the moving piece exposed. I am not sure what causes this; it seems that exposing requires event processing, but not always. The flashing of pieces did not work at all in the GTK build before I added a DoEvents() before the delay in the flash loop. But for move animation it seems to work partially. Putting DoEvents in the event processing is dangerous, as XBoard relies on events not interrupting each other. If new engine moves would come in while XBoard is still flashing the piece from a previous move, the behavior might be undefined...

[JoshPettus]

I'll keep playing with it, so far I see nothing egregious. I actually haven't seen the exposed problem. Sometimes part of the arrow overlapping the end square does not show up until the move has been completed. This is especially noticeable with the move flash.

[hgm]

This is really a drawing problem: for the flashing I just alternate drawing the piece and an empty square, without re-drawing the arrow all the time. Perhaps I should do such a re-draw, but the flashing and the arrow seem alternative solutions for the same problem, and the arrow is so conspicuous that flashing isn't really helpful when you have it (and in contrast to the arrow, it is time consuming). So my assumption was that they would not be used at the same time.

A similar problem exists with move animation, where the part of the arrow in the from-square gets erased when the piece moves out of it. Normally animation is so fast that this is hardly noticeable, though.

[JoshPettus]

Honestly I agree, and even then it's not permanent. There is probably other things we can work on. Good find loading an empty file. I wouldn't have thought to try that.

[hgm]

I did not think about that either. I just randomly picked a game file to load, for testing the Analyze Game command, and it happened to be an empty one. I still have no idea how I could have created an empty PGN file...

Except from restructuring the texi file I think this leaves my TODO lis for 4.9.0 empty. Perhaps I could still add a -fen option to redefine the start position of the startup -variant. This can now be done with -loadPositionFile, but it is always a bit of a pain that you have to make an external file for that.

[hgm]

I did not only add a -fen option, but also a -men option, which does the same as the VariantMen tag in a PGN file. So you can now redefine piece moves from the command line. Which could be useful for variants for which there is no engine. E.g. try

xboard -men "Q:mcpafmcpavK;B:mBcaibB" -ncp

and see how Queen and Bishop move!

[JoshPettus]

Wow that is crazy!
Works great!

[hgm]

Unfortunately I just discovered that the arrow highlighting in the secondary board window (for ICS background observe) is totally messed up now...