Xboard sluggish on OSX

[mvk]

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.

[JoshPettus]

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]

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.

[hgm]

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]

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.

[hgm]

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]

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.

[hgm]

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]

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.

[hgm]

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.