Xboard sluggish on OSX

Discussion of anything and everything relating to chess playing software and machines.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
mvk
Posts: 589
Joined: Tue Jun 04, 2013 8:15 pm

Xboard sluggish on OSX

Post by mvk » Sat Mar 12, 2016 11:26 pm

Since about a week or so I found that Xboard has become unbearably slow on OSX.

I'm normally using the installation from macports, because that allows me to use multiple boards simultaneously. (eg. being able to be on FICS as well as running a local game in another window, and being able to launch different use cases from the command line from an alias).

All was fine until one or two weeks ago. I'm not sure what changed. Maybe just a "sudo port upgrade outdated". I really don't remember.

I uninstalled xboard from macports and reinstalled to no avail.
I upgraded to El Capitan to no avail.
I removed all macports and reinstalled.
I seem to have gone from 4.7.3 to 4.8 doing that. Problem still there.

The symptom is that all drawing is sluggish. You can see the arrow being drawn. You can see that long arrows take more time to draw than short ones. You can see it updates the to and from square twice for each move. When the whole board changes, you can see the order in which the squares are updated. When you follow a fast game on FICS, the GUI update is so slow that the display can be more than a minute behind from reality, all the time updating moves that are played faster than xboard can keep track of. When you let two engines play 1 0 or so, it does nothing but updating the board and the menus are inaccessible.

Any others with similar problems recently? It used to be very snappy.
[Account deleted]

JoshPettus
Posts: 730
Joined: Fri Oct 19, 2012 12:23 am

Re: Xboard sluggish on OSX

Post by JoshPettus » Sun Mar 13, 2016 5:23 am

Can't say it sounds directly like an XBoard problem, although I take it you haven't experienced slowness in other areas? I wonder what could have changed in the course of the week? You did run a macports update?

mvk
Posts: 589
Joined: Tue Jun 04, 2013 8:15 pm

Re: Xboard sluggish on OSX

Post by mvk » Sun Mar 13, 2016 8:41 am

As I said I have done all that. I was thinking of some XQuartz or widget kit issue, but there is no slowdown in other apps as far as I'm aware of.
[Account deleted]

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

Re: Xboard sluggish on OSX

Post by hgm » Sun Mar 13, 2016 8:56 am

What you describe sounds like it is an issue in the Cairo drawing library, not so much in the widget set. XBoard drawing is doubly buffered, i.e. it first performs the complete draw on a memory bitmap, and then copies the affected area to the display.

Can you see if the elements it draws (like squares with a piece in it, or a square area of the board containing the arrow) appear in a flash, just with very long delays between them, or whether they slowly grow? (Probably best seen on a long diagonal arrow.) In the latter case it would be the copying of the memory bitmap to the display that is the culprit. Not sure which library would handle that.

mvk
Posts: 589
Joined: Tue Jun 04, 2013 8:15 pm

Re: Xboard sluggish on OSX

Post by mvk » Sun Mar 13, 2016 9:43 am

I've made a screen recording containing fragments of two games: https://marcelk.net/2016-03-13/xslug.mov

At 1:24 you can observe a "long move" (Ra1xa8) with the arrow being drawn square by square for example, with the previous arrow still partially drawn. Perhaps it is some setting of some kind somewhere but I can't imagine what yet.

Image
[Account deleted]

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

Re: Xboard sluggish on OSX

Post by hgm » Sun Mar 13, 2016 11:10 am

I can get similar behavior when I put an usleep(100000) in GraphExpose(). What actually happens is pretty sick anyway; it seems to redo the move without animation, and even redraw the arrow. I do occasionally test with the animation frame rate very slow, to see what happens, but that does not affect what happens afterwards. Which apparently is too fast to see, normally.

But it does seem that the problem is extremely long latency in handling of the copying from the memory bitmap to the display. XBoard does this on a per-square basis. The actual drawing seems to occur fast enough in the movie; I cannot discern any raster scan within one square. But there seems to be a pause between the drawing of different squares.

mvk
Posts: 589
Joined: Tue Jun 04, 2013 8:15 pm

Re: Xboard sluggish on OSX

Post by mvk » Sun Mar 13, 2016 1:11 pm

Can there be some other activity in the loop from xboard's point of view? A failed attempt to start a soundprogram, a secure socket communication to the x server, or something of that type? Anything that could have been affected by an unfortunate change in the system. (Just guessing, because /usr/bin/afplay is of date Jan 14, although I'm pretty sure the problem is not that old)

I temporarily removed my ~/.xboardrc to no avail BTW.
[Account deleted]

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

Re: Xboard sluggish on OSX

Post by hgm » Sun Mar 13, 2016 8:10 pm

Nothing comes to mind. XBoard isn't doing anything else during animation. Event handlers are not interruptable, and the animation is a loop with an usleep call in it that completes the animation before XBoard can start handling anything else.

mvk
Posts: 589
Joined: Tue Jun 04, 2013 8:15 pm

Re: Xboard sluggish on OSX

Post by mvk » Sun Mar 13, 2016 9:41 pm

I've made some good progress: when I run the same xboard from a newly created user account, the issue is gone. So it must be some very local thing.
[Account deleted]

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

Re: Xboard sluggish on OSX

Post by hgm » Sun Mar 13, 2016 10:33 pm

That is truly weird. Perhaps some setting of the desktop.

If you ever figure out what exactly caused it, let is know! In any case I will try to clean up the drawing process a bit.

Post Reply