I just tried the second board observing a game of bughouse. The new resizing is very much an improvement, and works great when shrinking the board. When expanding however, the window expands, but the redrawn board only fills the space of the old size and you only see a portion of the board. Only when you resize the second window does it recacluate the draw size to be the size of the main board.
Xboard sluggish on OSX
Moderators: hgm, Rebel, chrisw
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Xboard sluggish on OSX
Hmm, I though I had fixed that. Apparently not reliably...
The problem is that the expose event that changes the size of the secondary window somehow does not refresh the canvas to the new size of the window.
The problem is that the expose event that changes the size of the secondary window somehow does not refresh the canvas to the new size of the window.
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: Xboard sluggish on OSX
I see the mailing list item you posted. Unfortunately, or fortunately, apple doesn't maintain their version of XQuartz anymore and leave that up to the XQuartz project. Hopefully they are aware, I'll check.
[EDIT] I checked their bugzilla, It doesn't look like it. I'm not sure I'm aware enough of the problem to make a useful bug report outside Your version of X server is slow, fix it. :-/
[EDIT] I checked their bugzilla, It doesn't look like it. I'm not sure I'm aware enough of the problem to make a useful bug report outside Your version of X server is slow, fix it. :-/
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Xboard sluggish on OSX
Can you put the following printf statement in GraphEventProc() in gtk/xoptions.c:
and then observe two ICS games, and enlarge the main window to trigger this error, to see what it prints?
Unfortunately it will print a lot, almost all from the main window (recognizable by a different hexadecimal number for the graph handle), as every mouse motion event will trigger this code. But the important thing is that once you are done sizing, you should also get an output for the other window.
Code: Select all
if(sizing) { // the memory buffer was already created in GenericPopup(),
// to give drawing routines opportunity to use it before first expose event
// (which are only processed when main gets to the event loop, so after all init!)
// so only change when size is no longer good
cairo_t *cr;
printf("new canvas %x %dx%d\n",graph,w,h);
if(graph->choice) cairo_surface_destroy((cairo_surface_t *) graph->choice);
Unfortunately it will print a lot, almost all from the main window (recognizable by a different hexadecimal number for the graph handle), as every mouse motion event will trigger this code. But the important thing is that once you are done sizing, you should also get an output for the other window.
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: Xboard sluggish on OSX
Here is what I got, hope it helpshgm wrote:Can you put the following printf statement in GraphEventProc() in gtk/xoptions.c:
Code: Select all
fics% new canvas d1438 485x485
new canvas d1438 485x485
new canvas d1438 485x485
new canvas d1438 485x485
new canvas d1438 485x485
new canvas d11e0 539x470
new canvas d11e0 634x554
new canvas d11e0 720x672
new canvas d11e0 727x683
new canvas d11e0 727x682
new canvas d1438 485x485
new canvas d11e0 681x681
new canvas d1438 485x485
-
- Posts: 2949
- Joined: Mon May 05, 2008 12:16 pm
- Location: Bordeaux (France)
- Full name: Julien Marcel
Re: Xboard sluggish on OSX
H.G., IIRC there had been discussions, a while ago, regarding a work-in-progress Cocoa version of XBoard. Has it been canceled ?
"The only good bug is a dead bug." (Don Dailey)
[Blog: http://tinyurl.com/predateur ] [Facebook: http://tinyurl.com/fbpredateur ] [MacEngines: http://tinyurl.com/macengines ]
[Blog: http://tinyurl.com/predateur ] [Facebook: http://tinyurl.com/fbpredateur ] [MacEngines: http://tinyurl.com/macengines ]
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: Xboard sluggish on OSX
Is this regarding Voice Over support?
That was MaddtheSane's project, and unfortunately he hasn't touched it since 2013 which was what brought me to look into GTK on OSX.
https://github.com/MaddTheSane/MacBoard
That was MaddtheSane's project, and unfortunately he hasn't touched it since 2013 which was what brought me to look into GTK on OSX.
https://github.com/MaddTheSane/MacBoard
-
- Posts: 2949
- Joined: Mon May 05, 2008 12:16 pm
- Location: Bordeaux (France)
- Full name: Julien Marcel
Re: Xboard sluggish on OSX
No, I'm talking about Chris Sears' OSXBoard port :JoshPettus wrote:Is this regarding Voice Over support?
That was MaddtheSane's project, and unfortunately he hasn't touched it since 2013 which was what brought me to look into GTK on OSX.
https://github.com/MaddTheSane/MacBoard
http://www.open-aurec.com/wbforum/viewt ... =2&t=52170
"The only good bug is a dead bug." (Don Dailey)
[Blog: http://tinyurl.com/predateur ] [Facebook: http://tinyurl.com/fbpredateur ] [MacEngines: http://tinyurl.com/macengines ]
[Blog: http://tinyurl.com/predateur ] [Facebook: http://tinyurl.com/fbpredateur ] [MacEngines: http://tinyurl.com/macengines ]
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: Xboard sluggish on OSX
Wow I thought it was the same guy. Guess not, Madd's name is C.W. Betts
Haven't heard from either in a very long time.
Haven't heard from either in a very long time.
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Xboard sluggish on OSX
Well, at some point Chris Sears stopped answering my e-mails.