Gm aui fixes+start gp dlgs

[wsu-cb]

No description provided.

[DLLarson]

A note to let you know I've seen the PR.

-Dale

[DLLarson]

I'm done looking through the code but I'm having trouble building it using the batch file. This happened to me last time but I can't seem to remember what I did to fix it.

D:\Dev\CBoard\G\cbwindows>build-all-configs.bat

D:\Dev\CBoard\G\cbwindows>echo on

D:\Dev\CBoard\G\cbwindows>rem change the following if your Visual Studio is installed somewhere else.

D:\Dev\CBoard\G\cbwindows>set VSROOTDIR="C:\Program Files\Microsoft Visual Studio"

D:\Dev\CBoard\G\cbwindows>rem execute in bat's directory

D:\Dev\CBoard\G\cbwindows>pushd D:\Dev\CBoard\G\cbwindows\

D:\Dev\CBoard\G\cbwindows>call "C:\Program Files\Microsoft Visual Studio""\2022\Community\VC\Auxiliary\Build\vcvars64.bat"
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.14.10
** Copyright (c) 2025 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

D:\Dev\CBoard\G\cbwindows>cmake -G Ninja -B out/build/x64-Debug -DCMAKE_BUILD_TYPE=Debug
CMake Deprecation Warning at CMakeLists.txt:3 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:11 (project):
  The CMAKE_CXX_COMPILER:

    C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.43.34808/bin/Hostx64/x64/cl.exe

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!

The folder it's looking for doesn't exist:

I updated my VS 2002 to the latest and that didn't help. Does anything stand out to you?

-Dale

[wsu-cb]

I'm done looking through the code but I'm having trouble building it using the batch file. This happened to me last time but I can't seem to remember what I did to fix it.

The fact that your installed compiler version is newer than the path cmake is using suggests to me that cmake is using out-of-date cached information. Can you try deleting the out directory?

[DLLarson]

Can you try deleting the out directory?

That fixed it. You 'da man! I thought I had a clean environment after PR checkout but I didn't. I added this solution to some notes I keep for rarely encountered tool issues.

Thanks for the insight.

-Dale

[DLLarson]

Hi Bill,

Some observations when running the programs...

• CBDesign always launches squashed vertically.
• Very sluggish UI particularly around resizing. I think we attributed it to MFC vs wxWidget bitmap conversions in the current code during rendering but I thought I'd mention it just-in-case. Not surprisingly the release code is snappier than debug and x86 is snappier than x64 but all is kinda sluggish.
• The color palette behaviour seems much more sane now. It's accurately scaling to proper size in high DPI graphics modes.
• Tiles and board scaling is very tiny in High DPI modes. I expected this but just thought I'd make note of it because at one point in the past I thought the tile palettes were scaling with HighDPI settings but now I don't see it. The CBDesign code is set to rely the program handling DPI scaling. The CBPlay code is still set to have the OS handle DPI scaling. For reference I've attached CBDesign vs CBPlay (where we ultimately need to be scaling-wise once the port is complete.) I know that fixing scaling wasn't part of this work but just thought I'd capture what I was seeing.

CBDesign scaling:

CBPlay scaling:

So other than the squashed app upon launch thing I think we're good to go with committing the changes.

-Dale

[DLLarson]

Could you refresh my memory on how was this file with well over 10000 lines produced? This can't be hand coded.

[wsu-cb]

see #137 (comment)

[DLLarson]

Same question for the XRC files. How was it produced?

[wsu-cb]

https://github.com/wxFormBuilder/wxFormBuilder.git (commit 9c98b020eed47ba18c20189448bfa59c42b93ab5) is a GUI editor for wxWidgets. It's native format is .fbp, but it can export .xrc. (I have actually contributed a couple features to that project as well to support the CB work.)

[wsu-cb]

Some observations when running the programs...

• CBDesign always launches squashed vertically.

I'm leaving the initial height at whatever wxWidgets and/or Windows decides to use. The width I forced to be approximately 5 times the width of the color palette because the default was just too narrow. I don't have any good heuristic for how to set the initial height. Would forcing the window to start maximized be better than the current state?

• Very sluggish UI particularly around resizing. I think we attributed it to MFC vs wxWidget bitmap conversions in the current code during rendering but I thought I'd mention it just-in-case. Not surprisingly the release code is snappier than debug and x86 is snappier than x64 but all is kinda sluggish.

I can't dispute that. I still hope that that performance will improve once the MFC bitmaps are no longer required, but I can't know yet.

• The color palette behaviour seems much more sane now. It's accurately scaling to proper size in high DPI graphics modes.

We both put some work into HiDPI for the color palette, but none of the other code. Unfortunately, even if we put in the HiDPI work for the tiles, I assume 125% and 150% scaling of bitmaps will always look blurry.

• Tiles and board scaling is very tiny in High DPI modes. I expected this but just thought I'd make note of it because at one point in the past I thought the tile palettes were scaling with HighDPI settings but now I don't see it. The CBDesign code is set to rely the program handling DPI scaling. The CBPlay code is still set to have the OS handle DPI scaling. For reference I've attached CBDesign vs CBPlay (where we ultimately need to be scaling-wise once the port is complete.) I know that fixing scaling wasn't part of this work but just thought I'd capture what I was seeing.

I suspect the CBDesign tiles shrank when it was switched to use program scaling instead of allowing the OS to auto-scale.

So other than the squashed app upon launch thing I think we're good to go with committing the changes.

I'm ready for you to merge.

[DLLarson]

Hi Bill,

I'm leaving the initial height at whatever wxWidgets and/or Windows decides to use.

Windows usually does an ok job with the default sizing. My guess is wxWidgets is setting the default size somehow.

Would forcing the window to start maximized be better than the current state?

I have some programs that do that. It can really be annoying on large screens. My first impulse is to click the full screen button to make it resizable. In our situation it may just snap back to vertically squashed.

I think 5 times taller would be ok too--or some font based scaling. Using the color palette as coarse guide is indirectly doing that.

But the thing that really stands out is that, upon closing, the program doesn't remember what it was changed to after adjusting it after launch. So the user is forced to do it all over again. That's what really made it feel odd to me. It was like it didn't like my readjustment so it went back to squished. When I launched the CBPlay programs it remembers layout and I was back where it was when the game was closed.

There are bigger fish to fry than this issue but I think in the end it needs to feel like a more natural result.

I suspect the CBDesign tiles shrank when it was switched to use program scaling instead of allowing the OS to auto-scale.

They are simply begin drawn pixel to pixel with zero scaling. My UI scaling is set to 175% so they come out really tiny. Basically unusable for most people (at least those without the eyes of an eagle.)

I assume 125% and 150% scaling of bitmaps will always look blurry.

I think that's acceptable given the alternative of it not working like other programs. But there may be more sophisticated bitmap rescaling techniques we can use other than simple stretch blitting.

I'll poke around to see if I can find something we can use. Recently I've been AI upscaling old DVD's with stunningly good results. I'm not saying machine learning is the solution here but there may be something in between available. A cursory (AI assisted search) result:

ImageMagick has an image resampler...

https://usage.imagemagick.org/resize/#resample

OpenCV Rescaling...

https://opencv.org/blog/resizing-and-rescaling-images-with-opencv/

Here's a C++ header only library that just does image rescaling...

https://github.com/avaneev/avir

One thing I noticed is that the toolbar buttons look pretty good right now and those are rescaled. At least I think they are because I never created multiple scale toolbar images.

I'm ready for you to merge.

I'll merge after I get an additional thumbs up after you review my comments.

-Dale

[wsu-cb]

...

Would forcing the window to start maximized be better than the current state?

I have some programs that do that. It can really be annoying on large screens. My first impulse is to click the full screen button to make it resizable. In our situation it may just snap back to vertically squashed.

I think 5 times taller would be ok too--or some font based scaling. Using the color palette as coarse guide is indirectly doing that.

I came up with a different idea: when I change the width, I also change the height by the same ratio, so it should preserve the aspect ratio of the default window size.

But the thing that really stands out is that, upon closing, the program doesn't remember what it was changed to after adjusting it after launch. So the user is forced to do it all over again. That's what really made it feel odd to me. It was like it didn't like my readjustment so it went back to squished. When I launched the CBPlay programs it remembers layout and I was back where it was when the game was closed.

There are bigger fish to fry than this issue but I think in the end it needs to feel like a more natural result.

I wasn't doing anything to preserve the layout, so it always went back to the default. However, after searching the wxWidgets code and docs, I have now found some support for preserving layout on shutdown, so I have added that to this PR. Note that this doesn't do anything about handling the views for a particular document, just the toolbars and palettes.

I suspect the CBDesign tiles shrank when it was switched to use program scaling instead of allowing the OS to auto-scale.

They are simply begin drawn pixel to pixel with zero scaling. My UI scaling is set to 175% so they come out really tiny. Basically unusable for most people (at least those without the eyes of an eagle.)

I assume 125% and 150% scaling of bitmaps will always look blurry.

I think that's acceptable given the alternative of it not working like other programs. But there may be more sophisticated bitmap rescaling techniques we can use other than simple stretch blitting.

...

One thing I noticed is that the toolbar buttons look pretty good right now and those are rescaled. At least I think they are because I never created multiple scale toolbar images.

I noticed that in your screenshots. I'm not doing anything about that explicitly, so I infer wxWidgets already has a reasonably good scaling algorithm.

I'm ready for you to merge.

I'll merge after I get an additional thumbs up after you review my comments.

If you like the layout updates, then I'm ready to merge.

[DLLarson]

I noticed that in your screenshots. I'm not doing anything about that explicitly, so I infer wxWidgets already has a reasonably good scaling algorithm.

Yep. That's what I'm thinking. Another area that may be improved is how I did rotated pieces. I thought they always looked kind of crappy. I did those by raster scanning the original tile at the rotation angles but no other improvements are done. I'll bet there are much better techniques out there. When I did mine approach the graphical power of Windows systems was much more primitive.

I came up with a different idea: when I change the width, I also change the height by the same ratio, so it should preserve the aspect ratio of the default window size.
If you like the layout updates, then I'm ready to merge.

The changes look great! A much better experience.

I'll merge your work. Thanks!

-Dale

[DLLarson]

For some reason the merged PR is failing the build on master. Something about a missing "resource.h" file.

I did a fresh clone of the master branch onto my computer and it builds fine. I'm confused why the Github build environment is failing. All I can think of is the Github environment is not up-to-date.

[DLLarson]

I noticed that in your screenshots. I'm not doing anything about that explicitly, so I infer wxWidgets already has a reasonably good scaling algorithm.

After playing with different DPI scaling, wxWidgets appears to not scale the toolbar images from their native size if the scaling is 150% or less. At 175% it looks like it doubles the native size to get the sharper image. On 150% and 125% the toolbar button size is scaled to the proper proportional size but has a small image in the center.

-Dale

[wsu-cb]

For some reason the merged PR is failing the build on master. Something about a missing "resource.h" file.

I did a fresh clone of the master branch onto my computer and it builds fine. I'm confused why the Github build environment is failing. All I can think of is the Github environment is not up-to-date.

According to git, cd4e4bc (which is the head of this branch and which Github's checks built successfully) is identical to the merged master, so the code should be OK. I did have to make build-all-configs.bat retry builds because we found non-deterministic failures there, so it's not really surprising that Github is also showing non-deterministic build results. I'm inclined to re-run the build again in a day or two, but maybe in the long term the .yml needs to retry builds as well.

[DLLarson]

I'm inclined to re-run the build again in a day or two, but maybe in the long term the .yml needs to retry builds as well.

Yep. You nailed it. This AM I re-ran the job and it worked fine. Makes a person wonder if they are leaving a known issue in-place because they offer an enterprise version of the service that costs money.