bugXBoard - Bugs: bug #27715, 2 (minor) graphic issues

 
 

bug #27715: 2 (minor) graphic issues

Submitter:  None
Submitted:  Fri 16 Oct 2009 08:53:33 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 23 Oct 2009 08:05:45 AM UTC, comment #17: 

All ok for me in xboard-4.4.1.20091022. Thanks

Anonymous
Fri 23 Oct 2009 04:37:14 AM UTC, comment #16: 

new version uploaded should be fixed now... please test again

Arun Persaud <apersaud>
Group administrator
Thu 22 Oct 2009 02:08:49 PM UTC, comment #15: 

I see in my enthusiasm, I regressed something. VariantSwitch should force a full redraw of the current board (boards[currentMove]), not of the initial position (what InitPosition(TRUE) would do.)

To prevent the flicker when giving an smoves command by hand, it would be better to leave Reset(FALSE, ...) in the mentioned position, and force it after the full move list has been read in stead (slightly after FeedMovesToProgram() is used to send the moves to the program):

    if (gameMode == IcsObserving && ics_gamenum == -1) {
/* Moves came from oldmoves or moves command
   while we weren't doing anything else.
   */
currentMove = forwardMostMove;
ClearHighlights();/*!!could figure this out*/
flipView = appData.flipView;
DrawPosition(TRUE, boards[currentMove]);
DisplayBothClocks();

I will change it accordingly.

H.G. Muller

Anonymous
Thu 22 Oct 2009 09:03:10 AM UTC, comment #14: 

I even do this:
  if(gameInfo.variant)
    Reset(TRUE, TRUE);
  else
    Reset(FALSE, TRUE);

This avoids the short popup of the initial position when going from normal -> normal, which should be the most common case.

ad (2):
There seem to be 2 typos in xboard.c line 2780-2781:
    XtSetArg(args[1], XtNright,  XtChainLeft);
    XtSetValues(menuBarWidget, args, 2);
Changing that to:
    XtSetArg(args[2], XtNright,  XtChainLeft);
    XtSetValues(menuBarWidget, args, 3);
removes uglinesses in the menubar when vertical resizing is done.

Anonymous
Tue 20 Oct 2009 11:13:44 AM UTC, comment #13: 

OK, it seems that indeed it is better to change the call here to Reset(TRUE, TRUE);. This would force Reset to do a complete redraw of the new position.

I guess in 4.2.7 this was not needed, as one only gets here from modes IcsIdle or BeginningOfGame, and in both cases this would already display the initial position of VariantNormal, or at least an 8x8 board with normal checkering.

To make the code a little safer in this respect, I will ask for a total redraw on two calls to Reset from the ICS code when changing games.

H.G. Muller

Anonymous
Tue 20 Oct 2009 09:05:41 AM UTC, comment #12: 

What happens (when doing a "smoves"-switch from bughouse to normal) is this:

in read_from_ics() the following is done:

Reset(FALSE, TRUE);  <-  This sets gameInfo.variant to 0
gameMode = IcsObserving; <- just before changing the game mode

Afterwards VariantSwitch() is called, which skips the required code, because it thinks the current variant is normal instead of bughouse.

Strange that this bug has only visual effects on my system, so I do a quick/dirty fix for my "special edition".

Anonymous
Tue 20 Oct 2009 07:52:43 AM UTC, comment #11: 

Correction: "VariantSwitch" gets called, but drops out at the beginning:

if(gameInfo.variant == newVariant) return;

Because "gameInfo.variant" is always 0 on that position, any switch to normal doesn't execute the remaining code.

Anonymous
Tue 20 Oct 2009 07:27:53 AM UTC, comment #10: 

Ad 1 : I don't see that "VariantSwitch" gets called when you switch from bughouse to normal in ICS-mode (with smoves command).
But exactly that would repair the problem. So I further investigate this.

Ad 2 : The menu bar is ok now. The title bar is not, but as I don't use the title bar, I don't really care.

Anonymous
Tue 20 Oct 2009 01:12:28 AM UTC, comment #9: 

issue nr 2) should be fixed... the other one couldn't be reproduced. Please test.

Arun Persaud <apersaud>
Group administrator
Mon 19 Oct 2009 06:30:30 PM UTC, comment #8: 

That's clear. My change wasn't meant to be a permanent fix. :)

My last sentence was badly formulated, should have been:

So if you do a fullredraw on any variant switch, that must be sufficient.

Anonymous
Mon 19 Oct 2009 04:43:34 PM UTC, comment #7: 

Yes, doing a complete redraw every time will of course help. But the whole idea of having this parameter is to not waste time on unnecessary redraws.

H.G. Muller

Anonymous
Mon 19 Oct 2009 03:15:25 PM UTC, comment #6: 

I did just a dirty change to see, if that helps:

void DrawPosition(fullRedraw, board)
     /*Boolean*/int fullRedraw;
     Board board;
{
    printf("FullRedraw: %d\n",fullRedraw);
    XDrawPosition(boardWidget, 1/*fullRedraw*/, board);
}

So I didn't see, where the calls are coming from, just which paramters are coming in at which time . And passing a 1 to "XDrawPosition" removed the effect.
On a switch to bughouse I saw:
FullRedraw: 1
FullRedraw: 0
On a switch back to normal I saw:
FullRedraw: 0
---------
So if you always do a fullredraw now, that must be sufficient.




Anonymous
Mon 19 Oct 2009 02:49:40 PM UTC, comment #5: 

Can you tell which call to DrawPosition exactly you had to fix? The one in VariantSwitch, which is invoked whenever XBoard receives a board from the ICS that does not fit the current variant, now does a full redraw. Which is the other one?

The fix I made to the menu bar (chaining the right edge to the left window edge) should preserve the size of the menu bar for all re-sizings of the window, even if there is a title bar next to the menu bar. All width change should be taken out of this title bar.

H.G. Muller

Anonymous
Mon 19 Oct 2009 01:56:40 PM UTC, comment #4: 

I debugged (1) a bit, because I feared it might be not reproduceable. I saw that when switching to bughouse mode "DrawPosition" is called twice. First with fullRedraw=1, then with fullRedraw=0.
When switching back to normal mode, "DrawPosition" is called only once with fullRedraw=0. Forcing fullRedraw to 1 in that case repairs that bug for me.

Also note, that in (2) there is a title bar (with -title) between menu bar and right window edge, that has issues with resizing.

Anonymous
Mon 19 Oct 2009 01:32:44 PM UTC, comment #3: 

OK, apparently the menu bar (which in my system is unobservable against the background) apparently did not stretch all the way to the right edge of the window, but was just the size of the menu strings. As a result scaling the window would scale the width of the menu bar proportionally, producing the effects you described.

I will fix it by chaining the right edge of the menu bar to the left edge of the window, so that the width of the menu bar will no longer vary when the window is resized.

Effect (1) I could not reproduce, but I have added a DrawPosition call to the function VariantSwitch for another reason, and that quite likely fixes this problem too.

Anonymous
Sat 17 Oct 2009 07:16:40 PM UTC, comment #2: 

Effect (1) suggests that the display is not updated after a size switch, and that perhaps a call to DrawPosition shoud be added somewhere to make certain it always is updated.

I will look into the resizing of the menu bar.

H.G. Muller

Anonymous
Fri 16 Oct 2009 01:22:30 PM UTC, comment #1: 

I tried this on a third system:

ad 1) : I wasn't able to reproduce this effect on that system.

ad 2) : The white rectangle isn't even visible there. But the bug shows when doing this:

xboard -variant courier

Then switch to variant "normal". The "Options" and "Help" menu items get cut off, when the board shrinks (on all 3 systems).

Anonymous
Fri 16 Oct 2009 08:53:33 AM UTC, original submission:  

I tested these also on a more recent system to reduce the risc of another Xlib related problem. The effects are identical on both systems, so here they are:

1. Logon to fics, and switch the board to bug- or crazyhouse mode, afterwards observe a classic game, e.g.:

ex BugBug 20
unex
ob -b

Some square colors an a and b files are wrong (black or light squares remaining from the bughouse mode). A "Filp view" repairs the board. Try severel times because sometimes it's correct.

2.  Whenever the board gets enlarged (e.g. with the above switch to bughouse) the white rectangular area behind the menu items ("File" "Mode" ...) gets enlarged too and extends to right of "Help".

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by apersaud (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-10-23 apersaud StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2009-10-20 apersaud StatusNone Ready For Test

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code