Xboard sluggish on OSX

[JoshPettus]

Oh boy, I forgot about the second board. I better take a look at that, see if anything else

[hgm]

I seem to have fixed the secondary board, but in combination with flashing and slow animation it still is a disaster. When the flashing is interrupted by a move from the other game it completely loses track of what it was doing, and part of the arrow will not be exposed, and then also not erased, so that later through accidental exposure for another reason (e.g. an arrow through the square in another direction) stray arrow fragments will show up.

To make the flashing robust will require completely different treatment of it. (Scheduling it as a delayed event.) Not sure if that would be worth it.

[JoshPettus]

secondary board has a lot of trouble with resizing with the main board. You better hope when the second board pops up that you like the results of two boards on your screen. Else you are really stuck, till you unobserve what it was watching, resize your main board, then observe your second game.

Shame we can't have it resize independently, I imagine it would be a lot of work or it would already be like that. I could see people wanting their second observe for bug house to be a smaller board in the corner.

[JoshPettus]

MVK asked me to try out XBoard via X11 server XQuartz. I tried it with both GTK and Xaw before and after your drawing improvements. Before, animations were awfully slow. Terrible even. I can only imagine how it would run if the computer were just getting out of sleep.. After your improvements it was noticeably faster, but still nowhere near as snappy as it is with the Quartz integrated GTK. Especially when the board is large. I remembered there was a noticeable improvement with Quartz version of GTK as oppose to X11, but I didn't remember it was this much.
I don't know, I have seen programs run very well in XQuartz, ( 3D Windows games running in Wine) So maybe something is strange with cairo. But it is obvious which is the best way to use XBoard on OSX.

[hgm]

secondary board has a lot of trouble with resizing with the main board. You better hope when the second board pops up that you like the results of two boards on your screen. Else you are really stuck, till you unobserve what it was watching, resize your main board, then observe your second game.

For me it is not that bad. The secondary board does not respond to its own sizing, however. You have to size the main board, and then on the next redraw the secondary board will adapt its size similarly. Perhaps I should redraw the secondary board immediately when the primary board is resized.

Occasionally it goes wrong, however, and then it goes badly wrong: the secondary board is not completely redrawn, but just partially updated with pieces of the new size in the new location. Occasionally the outer window of the primary board does not snap back to the newly calculated board size either, and I suspect these events are related.

Shame we can't have it resize independently, I imagine it would be a lot of work or it would already be like that. I could see people wanting their second observe for bug house to be a smaller board in the corner.

Indeed, XBoard creates only one set of Cairo bitmaps from the SVG pieces, and uses those for all drawing.

[hgm]

After your improvements it was noticeably faster, but still nowhere near as snappy as it is with the Quartz integrated GTK.

The improvements do not really address the problem; they just avoid superfluous drawing.

What happens if you switch animations off? XBoard move animation is based on drawing all frames of the animation in the handling of a single event (with a 'busy-waiting' delay between them), i.e. it does not allow other events to be processed in the mean time. But for flashing pieces this badly failed; I did not see anything flash at all unless I called DoEvents() immediately after the GraphExpose call that was supposed to show the flashing piece. So it seemed that to make something actually visible after the program copies it to the screen takes processing of other events. We don't do such processing during animation, however. And yet it shows on the screen, although for me I often see pieces displayed only partially. So there seems to be something sick here, and it could very well be related to the slowdown.

If switching off animation helps, can you test what happens if we allow event processing during animation? By adding a DoEvents() call in FrameSequence (in board.c) like this:

Code: Select all

  for &#40;n = 0; n < nFrames; n++) &#123;
    AnimationFrame&#40;anr, &&#40;frames&#91;n&#93;), piece&#41;;
DoEvents&#40;);
    FrameDelay&#40;appData.animSpeed&#41;;
  &#125;

This is not an acceptable solution, because it could start processing new moves while aniation of old moves is still in progress, but when oves do not come in too fast, it could give us an idea if this triggers the problem.

[hgm]

I improved the situation with respect to the secondary board a bit: resizing the main board now leads to a immediate resizing plus a full redraw of the secondary board, rather than waiting with this for a move to occur there. (I guess the fact that it messed up so badly was collataral damage from the more efficient redrawing; before, when arrow highlighting was on, it seemed the board was always drawn completely, and the secondary board always uses arrow highlighting.)

Sizing the secondary window has no effect on the board size, however, and just clips off part of it or leaves a white margin. I am not sure what we would want it to do, given that in the current drawing framework the board sizes have to be equal. I suppose we should not allow the user to resize it at all.

[JoshPettus]

Turning off animation is much better and instant (especially when you get rid of the extra drawing in the current code). But even with the DoEvents() animation was still slow. (Was it suppose to be better?) It's really bad with dragging pieces where the piece follows the cursor a mile behind, and takes 5-10 seconds to get to the square you want. Worse then Engine moves as it must follow every tiny movement of the mouse.

[hgm]

(Was it suppose to be better?)

This is what I wanted to test. The theory was that we would somehow confuse the X-server by flooding it with expose events from the animation that could not be processed before the animation finished. But apparently that is not the problem; in dragging the mouse-motion causes separate events anyway, with ample opportunity to process other events in between.

I have little hope we can solve this. The problem does not seem to be in XBoard. It seems to be in XQuartz. I don't think XBoard does much that is out of the usual. We follow the wide-spread recommendation to keep a 'buffer canvas' that follows the size of the drawing area (through expose events triggered by resizing), and do all drawing there. And then copy any exposed area (from expose events that kept the size of the window the same) from that buffer canvas to the window. All the system sees should be the copying of rectangular areas that had a changed image or need to be refreshed on the display because something else spoiled them there. I don't know what else we could do, to get anything displayed.

What we do works well enough on Linux...

The problem does seem to hit other applications as well:
http://prod.lists.apple.com/archives/x1 ... 00013.html

[JoshPettus]

Yeah and it works just fine in the Quartz version of GTK, so I'd agree. Something is strange with XQuartz