Xboard sluggish on OSX

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

Moderators: Harvey Williamson, Dann Corbit, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
hgm
Posts: 25407
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Xboard sluggish on OSX

Post by hgm » Wed Mar 23, 2016 7:44 pm

JoshPettus wrote:Here is what I got, hope it helps
Can you try the latest commit? I now made it more robust by testing on every drawing action whether the buffer canvas still has the correct size, and replace it if it hasn't before the drawing is done.

Also check the sluggishness again: before, every expose request from a board modification did obtain the size of the widget, to see if the expose event was caused by resizing or by uncovering. This might have driven up the load on the X-server, and is unnecessary on events from which we already know they are caused by drawing.

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

Re: Xboard sluggish on OSX

Post by JoshPettus » Wed Mar 23, 2016 10:20 pm

The resizing is a lot better! Thanks a lot! Regarding speed, I think it might be a little better, tolerable even. Moving pieces yourself is still very slow.

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

Re: Xboard sluggish on OSX

Post by hgm » Thu Mar 24, 2016 9:14 am

Well, I cannot think of anything significantly simpler than what XBoard does now. It just copies any changed areas in the board drawing to the display. In particular, when dragging a piece, it must erase the piece in its previous position, and redraw it in its current position. To do that without flicker (which might make the piece seem transparent, because you see what was behind it) it does this by first drawing the L-shaped area of the old piece that is not covered by the piece anymore, (as two rectangles), and then the square area with the piece in its new location. So 3 expose events in total. I guess this could be collapsed into a single expose event by exposing the rectangular area that both contains the old and the new piece, at the price of copying a larger area.

But if it is noticeably slow, even making it 3 times faster is not really a solution. This whole thing should be lightning fast, and if it isn't, something is very sick. I think we do have every right to complain to the XQuartz developers. I don't see this latest version doing anything out of the ordinary, and the results utterly suck.

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

Re: Xboard sluggish on OSX

Post by JoshPettus » Thu Mar 24, 2016 1:17 pm

No, I agree it's not our fault. On the plus side these drawing improvements havn't been a waste. I don't know if it's because the svg pieces are more complicated or whatever, but the traditional xiangqi board you and I created use to be slower then the default pieces. Now they behave just as fast.

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

Re: Xboard sluggish on OSX

Post by JoshPettus » Thu Mar 24, 2016 1:46 pm

What is really strange is user piece moving works fine in ancient xboard 4.2.7. Did we change how the pieces were handled since then for cairo? If I can narrow it down to ciaro I could make a slightly better bug report.

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

Re: Xboard sluggish on OSX

Post by hgm » Thu Mar 24, 2016 2:31 pm

Cairo now handles the copying of pieces to the screen. To be specific, we call

Code: Select all

cairo_t *cr = gdk_cairo_create(widget->window);
to create the drawing target that represents the screen at the 'widget' we want to draw in, on which we then draw through

Code: Select all

    cairo_set_source_surface(cr, (cairo_surface_t *) bufferCanvas, 0, 0);
    cairo_set_antialias(cr, CAIRO_ANTIALIAS_NONE);
    cairo_rectangle(cr, eevent->area.x, eevent->area.y,eevent->area.width, eevent->area.height);
    cairo_fill(cr);
    cairo_destroy(cr);
For Xaw we use

Code: Select all

cairo_surface_t *xxx = cairo_xlib_surface_create(xDisplay, XtWindow(widget), DefaultVisual(xDisplay, 0), w, h);
cairo_t *cr = cairo_create(xxx);
to create the drawing target in the Xaw widget. (Which then uses the same code for drawing on it.)

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

Re: Xboard sluggish on OSX

Post by JoshPettus » Thu Mar 24, 2016 3:46 pm

Thanks!

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

Re: Xboard sluggish on OSX

Post by mvk » Wed Mar 30, 2016 7:55 pm

Today the macports xboard/xquartz combo is relatively snappy again on my main user account. Not great, but much better than it was 1 week ago (or yesterday for that matter): the application is even workable for now. I have not accepted any upgrade or macports update that I'm aware of.

The only thing I recall doing today that is slightly out of my normal routine is hooking up to an external projector for several hours at work, albeit while using my secondary user account. But the primary account might have been running in the background. After hooking up the macbook went into mirroring mode, with the desktop accepting the rather high resolution of the projector and probably losing retina mode while doing so. Interestingly, while powerpoint was displaying, it was operating in dual-screen mode: full slide on the projector and slide/speaker notes/clock/next slide preview/etc on the laptop screen. So there is a lot of flip flopping between modes it seems.

Having exhausted all other leads, this might give some new perspective. All the resolution and display configuration flipping might be a trigger to something nasty occurring under the hood. Speculating of course, but I don't use this specific projector a lot. The last time might as well have been 1.5 month ago, around the time the issue started.
[Account deleted]

Post Reply