winboard time management

[xr_a_y]

TC was 20sec+0

I didn't switch off animation ... let me try ... wow this is way better.

Do you have any clue why this is not happening on xboard ? only on winboard ?

Thanks !

[Joost Buijs]

Winboard uses the Cairo library which is known to perform badly under Windows because it uses the outdated Win32 GDI as backend. Still strange that it gives such a big latency (assuming that the graphics are handled in a separate thread).

[hgm]

WinBoard does not use Cairo; it uses Windows API directly. But animation is intentionally slow (or it would not be visible); a move is a fixed number of frames, an the frame rate is selectable through a command-line option. So it will take some time to show the animated move (60 ms?), which normally goes in parallel with engine thinking, but would add to the thinking time if the engine moves before the animation completed.

It should be the same in XBoard. But perhaps move animation was off there by default.

[Joost Buijs]

WinBoard does not use Cairo; it uses Windows API directly. But animation is intentionally slow (or it would not be visible); a move is a fixed number of frames, an the frame rate is selectable through a command-line option. So it will take some time to show the animated move (60 ms?), which normally goes in parallel with engine thinking, but would add to the thinking time if the engine moves before the animation completed.

It should be the same in XBoard. But perhaps move animation was off there by default.

Sorry, I am wrong than. In the past I looked at the xboard code and that was using Cairo, I didn't know Winboard is using the Windows API directy now, but I assume it is still using the old Win32 GDI?

Is it really necessary to wait with sending the engine move until the animation is finished? Eg. sending the moves to an asychronous rendering pipeline, I know this would look funny when you (and the opponent) play a number of sub (60 ms.) moves in a row, but in practice this will never happen.

[xr_a_y]

It should be the same in XBoard. But perhaps move animation was off there by default.

It was activated on xboard too.

[Ras]

I know this would look funny when you (and the opponent) play a number of sub (60 ms.) moves in a row, but in practice this will never happen.

With really fast time controls like 1 second per game, this is even normal. Maybe it would be an idea to cancel the animation if the move arrives before the animation is over. Of course, having the user switching it off also works, but dynamically cancelling it upon need would combine the best of both ways.

[Joost Buijs]

I know this would look funny when you (and the opponent) play a number of sub (60 ms.) moves in a row, but in practice this will never happen.

With really fast time controls like 1 second per game, this is even normal. Maybe it would be an idea to cancel the animation if the move arrives before the animation is over. Of course, having the user switching it off also works, but dynamically cancelling it upon need would combine the best of both ways.

I agree, when you play a series of very fast games (for instance to tune your engine) this could happen, but I would never use a GUI to do this. For self-play it is usually the fastest to have both engines communicate with each other within the same process, and for playing against other engines I would take something like little blitzer or cutechess-cli. Graphically rendering a chessboard without animation still takes a serious amount of time, and this is something you don't want when you have to play thousands of very fast games.