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 !
winboard time management
Moderators: hgm, Rebel, chrisw
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
-
- Posts: 1564
- Joined: Thu Jul 16, 2009 10:47 am
- Location: Almere, The Netherlands
Re: winboard time management
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).
-
- Posts: 27829
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: winboard time management
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.
It should be the same in XBoard. But perhaps move animation was off there by default.
-
- Posts: 1564
- Joined: Thu Jul 16, 2009 10:47 am
- Location: Almere, The Netherlands
Re: winboard time management
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?hgm wrote: ↑Sat Jun 16, 2018 8: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.
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.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: winboard time management
It was activated on xboard too.
-
- Posts: 2488
- Joined: Tue Aug 30, 2016 8:19 pm
- Full name: Rasmus Althoff
Re: winboard time management
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 wrote: ↑Sat Jun 16, 2018 8:56 amI 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.
Rasmus Althoff
https://www.ct800.net
https://www.ct800.net
-
- Posts: 1564
- Joined: Thu Jul 16, 2009 10:47 am
- Location: Almere, The Netherlands
Re: winboard time management
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.Ras wrote: ↑Sat Jun 16, 2018 12:03 pmWith 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 wrote: ↑Sat Jun 16, 2018 8:56 amI 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.