hgm wrote: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.
Not solved yet, but I think I can rule out some suspects:
- xboard and cairo
Because when I trace the process I see the cairo calls below GraphExpose are fast, but then wait hundreds of milliseconds on _xbc_conn_wait + poll. So there it is waiting for the X server.
- Fonts
I cleared all of $HOME/Library/Fonts
- Xquartz.app / X11.app
Because I installed an ancient version (2.7.7) and the problem remained.
The interesting thing I just noted is that whenever I cover the board area of the window, but leave the clock area exposed, everything appears to run a lot faster as observed from the speed at which the clocks change the side to move indication. If I increase the board size the problem becomes worse. So the slowdown seems proportional to the visible area of the Mac window. And also it seems a bit faster in the first few moves after startup. But I didn't observe any obvious memory leak.
I don't really believe that XQuartz can be aware of what is visible on the Mac desktop as that sounds like a 1980s type of optimisation. But maybe I'm wrong. If I'm right it is in the Mac desktop sw itself. Ugh.
There was a "login item" for Skype (in fact two times) and one for "iTunesHelper". The latter and one of the "Skypes" showed some orange alert sign/triangle and "Kind / Unknown". Removing all login items and then a logout/login makes XQuartz as snappy as it was before.
I foremost suspect Skype for it has a desktop sharing function I sometimes use in conference calls (however, usually not on the affected user account I reserve for personal use including chess). The second user account, the one I use at the office, didn't have these login items, and was fast as I reported earlier.
I think ituneshelper is something that just helps in syncing ipads and phones.
The euphoria is short-lived The slugginess returns after a few dozens of games. A logout/login still makes xboard update fast again. Maybe there were two similar issues and removing Skype only solved one of them. To be continued.
Can it be that there is some resource leak in one of the libraries that eventually causes the performance degradation, and does so faster when more programs are using that library?
hgm wrote:Can it be that there is some resource leak in one of the libraries that eventually causes the performance degradation, and does so faster when more programs are using that library?
Not sure anymore. The symptoms are now rapidly changing: the second user account now shows the same problem. The problem doesn't always reset with a relogin anymore, or even a reboot. Triggering the Display Sleep mode (making the screen black, I set it to 1 minute to test) immediately throws the system from fast into slow mode. I tinkered with "Automatic graphics switching" setting in the energy saver panel to no avail.
I fear it might be as low-level as switching on/off the HW acceleration due to a thermal problem. I don't know how to test that hypothesis.
Some more notes. As nobody else seems to experience similar issues I'm using this thread now as a way to organise the trouble shooting for my own purpose, but feel free to chime in.
I can rule out hardware now: On one user account it is slow while simultaneously in another virgin account it is snappy. I really mean at the same time.
Issue is only noticeable when the move highlighting with the arrow is enabled. This is because xboard is very inefficient. It redraws more than 100 squares for each move. With XQuartz Debug you can enable "Flash screen updates", and then this sequence becomes very visible:
1. First animate the move. This is just a few updates, about 10 or so.
2. Then it draws the arrow by redrawing every square, one by one, but with the piece on the original square. This also clears any previous arrow.
3. Then it draws the arrow again, square by square with the piece on the target square.
It is horrible, but normally hardly noticeable because it GPU is fast. But the flickering of the piece being moved twice has always been there and it is for this reason. It would be a nice improvement point. Maybe even better to draw the arrow as one full board rectangle, instead of 64 clips.
The activation of Energy Saver "Display Sleep" makes things go very wrong instantly: After the screen has blacked out and returned by key press, xboard is unusable. This might be an additional problem with the same symptom, because in this mode it is even slower than slow: Think of almost 2 seconds per move. It is recovered by logging out and logging in again. Restart of just XQuartz is not sufficient, and a full reboot is not needed to recover this mode.
There is a history effect with respect to how long (accumulated overall usage) xboard has been used by a user. My regular user account never has snappy updates anymore. My secondary account is a bit faster but not as fast as it used to be. My new virgin test account is still snappy, and only becomes slow after display sleep, but recovers with login. Very weird and I don't see what persistent store can be used as "memory" here. (Library/Cache, logs?, some desktop setting, no idea yet, it all looks the same).
Resource usage appears the same under all conditions. One full CPU for each engine (using pondering), typically about 5-10-15% for xboard, and XQuartz takes about 10-15-25%. They never go to full CPU load. Memory looks stable and ok. Plenty of free memory, no leaking observed. Disk I/O is typically zero. Network is typically idle. No suspects there.
I don't really remember what triggered the problem some weeks ago. Might be a full update of all of macports. Might be an apple update. Might be something else.
mvk wrote:1. First animate the move. This is just a few updates, about 10 or so.
2. Then it draws the arrow by redrawing every square, one by one, but with the piece on the original square. This also clears any previous arrow.
3. Then it draws the arrow again, square by square with the piece on the target square.
This is awful. Part of the problem is that the DrawPosition() calls made from the backend code have a parameter that can force a total redraw, rather than the very efficient changes-only redraw WinBoard and XBoard have had from the beginning. The latter was based on assumptions that are no longer valid, however. Such that applying or erasing highlights could be done without damaging anything. For the arrow this obviously is no longer true. One problem is that things have always worked differently in WinBoard and XBoard: in WinBoard the highlights were drawn as part of the board drawing, but in XBoard the call to define the new highlights was already drawing them. It seems that Step 2 is a consequence of changing the highlights, which in this particular case was superfluous, as an immediate board update would already follow. And because the highlights involve an arrow, it has to update many squares (with as unwanted side effect that it redraws the piece on the from-square, which was sneakily removed from the screen by the animation process, but on XBoard's internal board is still sitting there). And drawing an arrow often means erasing a previous one, which might not always be in an known location.
I guess XBoard's drawing should be rewritten to defer drawing of the highlights to the DrawPosition() call. And perhaps draw the arrow only after the move animation, because this animation would erase the part of the arrow that is in the from-square (as a side effect of erasing the piece there) anyway.
The fixed render seems to be working great! I even noticed a little difference in the osxapp with Quartz render. I am however noticing a little graphical glitch which especially noticeable with line-gap. Looks like not all of the line gap is being updated back to black once a new move made.
Whar exactly are you doing to get this? (Two Machines, Edit Game, click-click or drag-drop moving...)
I don't see anything like this. And I don't understand how you could have it: XBoard has a board-size array 'damage', where you can mark everything that is altered by routines other than a board redraw (such as dragging a piece, which clears the from-square, or drawing highlights). The redraw routine will then 'expose' the damaged squares as well as those it has to redraw itself (because the occupant changed), meaning it copies them from the bitmap buffered in RAM to the screen. This to allow the squares to collect all modifications from different routines (like occupant, on top of which you draw a marker dot, on top of which you draw part of an arrow, and around which a highlight border is drawn) before you copy the area to the display (thus minimizing the required number of expose events, and suppressing flicker).
The routine that sets the highlights (and the one that clears them, which is implemented as setting them to an invalid square) now always marks the old highlighted square as 'damaged'. And in a way that would not only expose the square itself, but also the border around it. (The same is done for all squares touched by the old arrow.) So any redraw of the board should erase them, and expose the change.
The slugginess returns after a few dozens of games. A logout/login still makes xboard update fast again. Maybe there were two similar issues and removing Skype only solved one of them. To be continued.
