v3.3.3.-beta1 - window command bar buttons badly formatted

One or two problems with window command bar buttons seem evident in v3.3.3-beta1. The symptoms affect buttons from the map only and possibly only in the main window, for modules where the main map is attached there.

Case 1: A dev version of C&C Napoleonics module. Buttons for map window are mis-aligned in v3.3.3. At least part of the issue is that the map buttons are squashed under v3.3.3 compared to v3.3.2. In this module html in is used in the text of button definitions.

[attachment=2]html button bar v3.3.2.jpg[/attachment]

[attachment=1]menu bar v3.3.3.png[/attachment]

Case 2: The current live version of C&C Ancients (v4.1). This module uses no text in button definitions. The difference is more subtle but can be readily demonstrated. Map buttons appear to have lost their lower border and are of a different size. Using GIMP to compare the buttons precisely; I have left the graphic at full size so that the effect can be seen more easily. Scroll sideways to see all the buttons to the right.

[attachment=0]CCA v4.1 menu bar v3.3.2 to v3.3.3 compare.jpg[/attachment]

Looks like Mac OS problem.

On Linux, they look exactly same:
[attachment=0]toolbar.png[/attachment]

Yay, let’s spend some more valuable time of the development team to fix an issue for a minority of the users, instead of fixing issues and add features for everyone.

That’s a bit concerning. Nothing comes to mind that should have done that. I’ll have a look.

Do any of the 3.3.3 builds here NOT have this problem?

vassalengine.org/~uckelman/tmp/

All toolbar buttons seem to use the same class, and the same styling. There is no place in the code that makes some of the buttons look different from others. None of this button code was changed. Nothing changed on Linux.

Would be interesting to hear whether Windows users see any change.

Otherwise, “Cannot reproduce” → “Won’t fix”?

No. I worked through every 3.3.3 build there and I saw the problem each time.

Other things I checked:-

  1. Tried using a non-Retina monitor. Still got the problem on the non-Retina monitor.

  2. Checked other windows within the same module (C&C Ancients v4.1); confirming that the problem only affects buttons in the map map.:
    [attachment=0]CCA button bar windows compare.jpg[/attachment]

  3. Checked what happens when the main map is detached from the main Vassal bar (show/hide checkbox selected). This made no difference, the button discrepancy still shows (tested for the C&C Napoleonics dev module).

What’s this “C&C Napoleonics dev module”, where can I get it so I can try to reproduce?

And, care to use “git bisect” to hunt down the exact commit that changed this between 3.3.2 and 3.3.3? You, yourself? Or another MacOS user who can reproduce this “bug”?

Knowing that it’s reproducible in 82454de29d19 gets us back a few weeks, as least.

One thing I learned while on my recent hunt through “old bugs” is that we have at least one place (Footprint.java) that sets a “RenderingHint” but then does not restore the previous state when it is done drawing. This, in certain situations, turns out to make (possibly among other things), the selection boxes for some units appear differently aligned (by one pixel on each axis) when movement trails are on, as opposed to when movement trails are off.

Am meaning to get to at least that instance and deal with it in a PR (I was partially delayed by the fact that the “right” solution, of having MovementRenderer restore the state, turns out to make the selection boxes all stay the same, except it does it in the way that makes the boxes look wrong/misaligned by one pixel, so I’m wondering if I actually ought to also turn the rendering hint on (rather than off) for the selection box draw).

Anyway this sure feels like a similar situation – maybe something changed the order certain things get done and so something that was depending on a wrong/sloppy setting could now be getting done a different way.

Maybe a red herring, but it strikes me a similar.

Thus spake Cattlesquat:

Am meaning to get to at least that instance and deal with it in a PR (I
was partially delayed by the fact that the “right” solution, of having
MovementRenderer restore the state, turns out to make the selection
boxes all stay the same, except it does it in the way that makes the
boxes look wrong/misaligned by one pixel, so I’m wondering if I actually
ought to also turn the rendering hint on (rather than off) for the
selection box draw).

There are only a few top-level paint methods. In Map.View.paint(), we
add all the hits for optimal font rendering so they filter down to
everything else painted on the map. It might be worth reviewing the
places where we set other RenderingHints, to see if they should be set
at the same time as the font hits. (Are there any places where we
actually want non-antialiased rendering?)


J.

This could be any of the hundreds of commits of the last couple months. It would really help if someone who could actually reproduce this did a “git bisect”. None on the development team has a proper Mac machine for reproducing this and so far it doesn’t sound like it appears on Windows and it’s confirmed to not appear on Linux.

Mac users minority wants an extra, so the Mac users can help the dev team with finding the source of the bug, otherwise we’re looking for the needle in the haystack.

If you’re not able to bisect, Mark, I might be able to check this on my Mac VM. Let me know.

Sorry guys, I am fully committed to helping with the testing, for the reasons flint says and more. Just a bit diverted at the minute… wedding anniversary. I will be back with the programme tomorrow… and yes, help with git bisect step would be appreciated.

I will post more on the CCN module too tomorrow. Stripping it down to help demo the problem for flint had the side effect of making the problem go away, so I want to see if I can narrow that down further too.

Mark

So, I went back to stripping out my CCN module step by step to find out what causes the problem to disappear when I did this before.

Got rid of most application specifics apart from the base setup and detached the map; none of this made a difference.

That left me with one thing I did “wrong” the first time; completely deleting the Global Options folder. When I did this, on re-entering the module (causing a re-tiling), the problem went away. Of course this is not a “fix”, but I hope it helps.

I tried the same with C&C Ancients v4.1 (deleting the Global Options folder which is “empty” and making no deletion of other stuff). Again, after re-start/re-tiling, the problem goes away… noting the deleting Global Options forces the main map to “detach” from the main Vassal window, I checked by comparing the buttons with a version of CCA where the map was detached:-
[attachment=0]CCA Global Options Deleted (top) compare to detached map.jpg[/attachment]

Links to the files referred to:-

  1. CCN stripped back but still showing the problem (start a new game to see):
    dropbox.com/s/gwki8kfi4kaz0 … .vmod?dl=0

  2. CCN with Global Options deleted.
    dropbox.com/s/davcjbez59agl … .vmod?dl=0

  3. CCA V4.1 with Global Options deleted. Try the first scenario. The buttons look correct, albeit now in an independent window.
    dropbox.com/s/6v5mbamaiv8sz … tions?dl=0

  4. CCA v4.1 with Global Options still in place but now the map is detached by setting the property for show/hide button. The version shows the error.
    dropbox.com/s/r3n3cyfgb2baq … 20map?dl=0

Let me know what else I can do to help. I can work my way through more Vassal builds but I will need help with git (happy to learn to do the work myself, if it’s possible to explain the steps required to someone otherwise unfamiliar with the tool).

Mark

Try VASSAL-3.3.3-SNAPSHOT-bug13319-61cafd3b4:

vassalengine.org/~uckelman/tmp/

This also contains a fix from Brian for the CSS styling bug you reported.

The mal-formed button change works. However, the problem of the Map buttons being smaller and missing a bottom pixel or two is still evident. For example, this updated comparison of C&C Ancients buttons (red highlighting added by me)…
[attachment=0]CCA button bar windows compare - not fixed.jpg[/attachment]

Brian’s CSS styling fix works and I will report that on the thread for that bug.

Try VASSAL-3.3.3-SNAPSHOT-bug13319-036d46758. Is that better?

Different but not better. Size is still smaller. The border is now complete but doubled up with dashed lines.

[attachment=0]CCA button bar windows VASSAL 3.3.3-bd388670.jpg[/attachment]

Thus spake marktb1961:

“uckelman” wrote:

Try VASSAL-3.3.3-SNAPSHOT-bug13319-036d46758. Is that better?

Different but not better. Size is still smaller. The border is now
complete but doubled up with dashed lines.

The dashed lines are drawn by debug mode of the layout used by those
buttons. That wasn’t supposed to be in the build.

Try VASSAL-3.3.3-SNAPSHOT-bug13319-2862090cd instead.


J.

As the image shows, the buttons are now fully formed, but they are still smaller in comparison to the module-level buttons to the left (v3.3.2 render is the underlying graphic; two layers on top show appearance under the new snapshot. Each button image in this module is 32x32 pixels, so they should all be the same size, as they are under v3.3.2.

The graphic shows that the v3.3.3 map buttons are narrower than before, narrower than the module-level buttons and possibly spaced closer together (the dividing line between buttons is not as thick for the map buttons under v3.3.3).

[attachment=0]CCA 4.1 menu bar new compare to v3.3.2.jpg[/attachment]