OpenBVE
OpenBVE copied to clipboard
Route map image isn't display at the tab change
Description
When we choose a route, and change 'Map' tab, the route map image is not show. To show, we have to change the window size. I think that at the press of 'Map' tab, the route image should be show directly, and not need cnange window size. I think that this issue has been from at least 1.6.0.
At the 'Map' tab select:
Window size changed:
Reproduction
This issue happens at OpenBVE's main program's. so no need any data.
Route
This issue happens at OpenBVE's main program's. so no need any data.
Train
This issue happens at OpenBVE's main program's. so no need any data.
Logs
This issue is not crash so no output any logs.
Related information
My PC's spec: OS:Ubuntu 20.04 LTS 64bit CPU:AMD® Ryzen 7 2700x eight-core processor × 16 Memory:31.3GB Graphic:AMD Radeon RX 590 Series (POLARIS10, DRM 3.40.0, 5.11.0-40-generic, LLVM 12.0.0)
Try the build from today. I can't reproduce this at the minute, but I've added a force redraw on the routemap when the tab changes. This will hopefully give it the poke it needs.
I tested at 20220103's build.
But still not shown.
I think that the trigger is not enable at tab change.
If I run on Wine, this process is works perfectly.
Reproducible on the following VM:
Lubuntu 21.10 (Mono 6.12.0.1xx): Something (Context menu, or a window) must be on top of the image, then that portion of the image will be shown. When you switch to another tab or resize, it will remain empty again.
Pop OS 20.10 (Mono 6.12.0.182, Latest): Image will always be blank no matter what.
Probably something to do with https://github.com/mono/mono/issues/12425 Tossing the PictureboxTest.zip attached on the above issue to both VM also results in the exact same behavior.
If we've got a VM which reproduces at my end I'll take a look, probably tomorrow.
Concerned this is timing related though, which may well mean it doesn't reproduce reliably. I've certainly tried a nice collection of VMs chasing :/
Dumping an Invalidate onto all pictureboxes into the main form tick method might help (the one which updates the joystick states etc), but that's horrendously brute-force and messing badly with Mono internals on something that should work.....
I can reproduce this on a PopOS 20.10 VM, but have no real answers I'm afraid. Have added some observations to the linked Mono bug, but it's clearly something mega-deep within where Mono interacts with the windowing system and timing, and I strongly suspect that any workarounds I add only have a limited chance of working on broken systems.