Page 6 of 6
Re: Xboard sluggish on OSX
Posted: Wed Mar 23, 2016 8:44 pm
by hgm
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.
Re: Xboard sluggish on OSX
Posted: Wed Mar 23, 2016 11:20 pm
by JoshPettus
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.
Re: Xboard sluggish on OSX
Posted: Thu Mar 24, 2016 10:14 am
by hgm
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.
Re: Xboard sluggish on OSX
Posted: Thu Mar 24, 2016 2:17 pm
by JoshPettus
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.
Re: Xboard sluggish on OSX
Posted: Thu Mar 24, 2016 2:46 pm
by JoshPettus
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.
Re: Xboard sluggish on OSX
Posted: Thu Mar 24, 2016 3:31 pm
by hgm
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.)
Re: Xboard sluggish on OSX
Posted: Thu Mar 24, 2016 4:46 pm
by JoshPettus
Thanks!
Re: Xboard sluggish on OSX
Posted: Wed Mar 30, 2016 9:55 pm
by mvk
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.