winboard time management

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
xr_a_y
Posts: 206
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: winboard time management

Post by xr_a_y » Fri Jun 15, 2018 7:55 pm

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
Posts: 746
Joined: Thu Jul 16, 2009 8:47 am
Location: Almere, The Netherlands

Re: winboard time management

Post by Joost Buijs » Sat Jun 16, 2018 5:45 am

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).

User avatar
hgm
Posts: 22575
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: winboard time management

Post by hgm » Sat Jun 16, 2018 6:18 am

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
Posts: 746
Joined: Thu Jul 16, 2009 8:47 am
Location: Almere, The Netherlands

Re: winboard time management

Post by Joost Buijs » Sat Jun 16, 2018 6:56 am

hgm wrote:
Sat Jun 16, 2018 6:18 am
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.

User avatar
xr_a_y
Posts: 206
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: winboard time management

Post by xr_a_y » Sat Jun 16, 2018 7:57 am

hgm wrote:
Sat Jun 16, 2018 6:18 am
It should be the same in XBoard. But perhaps move animation was off there by default.
It was activated on xboard too.

Ras
Posts: 989
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: winboard time management

Post by Ras » Sat Jun 16, 2018 10:03 am

Joost Buijs wrote:
Sat Jun 16, 2018 6:56 am
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.
Rasmus Althoff
https://www.ct800.net

Joost Buijs
Posts: 746
Joined: Thu Jul 16, 2009 8:47 am
Location: Almere, The Netherlands

Re: winboard time management

Post by Joost Buijs » Sat Jun 16, 2018 1:26 pm

Ras wrote:
Sat Jun 16, 2018 10:03 am
Joost Buijs wrote:
Sat Jun 16, 2018 6:56 am
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.

Post Reply