Show/hide model toggles under "Edit Display Elements" only responds to clicks at top left corner on MacOS

[nkaminski]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. In the sequencer tab, right click on a model and choose "edit display elements" option
2. Click on the eye icon to try to hide the model
3. Observe that it is necessary to click outside of the eye icon at the very top left of the row for the UI to respond and hide the model.
4. Right click on one model and choose "hide all"
5. Observe same behavior - clicking on the eye icon does not work and you need to click above and to the left of such to unhide models.

Expected behavior
Single clicking the eye icon for a model in the display elements pane should toggle the visibility of that model

Screenshots
Video of the issue attached

Versions (please complete the following information):

• OS: MacOS Sequoia 15.1.1 (24B91)
• xLights version 2024.19

Based on further analysis, I believe that having macOS rendering on a HiDPI/Retina display is required to trigger this behavior.

Xlights.hide.unhide.bug.480p.mov

[nkaminski]

I can also confirm that this behavior does not happen on Windows and is exclusive to the Mac OS build of xlights.

[cybercop23]

Can't duplicate. Tried my existing show folder and a fresh folder with only a Master View (like you have) and once I click the eye-ball, it hides it, I can unhide it, hide all show all.

[nkaminski]

Will try as a separate macOS user to see if this is related to a specific setting or the like later today.

[derwin12]

Tools->Package logs might help us figure this out..

[nkaminski]

Can confirm that the behavior persists when tested using a separate show directory as well as a separate MacOS user. @cybercop23 can you confirm that you are using MacOS Sequoia 15.1.1 (24B91) on arm64 (apple silicon) as your platform?

I was also able to reproduce the same behavior on an Intel mac running MacOS 14.4.1 Sonoma as well.

Logs after reproducing this with a dedicated show directory and empty sequence containing only 2 models:
xLightsProblem.zip

[nkaminski]

I also opted to experiment with rolling back to earlier versions of xLights obtained from https://dankulp.com/xlights/archive/ as I recall this function working as it should in the past and have made the following observations:

• xLights-2023.18 - working
• xLights-2023.22.1 - working
• xLights-2024.02.1 - NOT working

Therefore the cause of this behavior seems to be something that was introduced between releases 2023.22.1 and 2024.02.1 - potentially related to the update of the wxWidgets library between these releases - 1372bbf ?

[cybercop23]

@nkaminski yes, I'm a Sequoia, M2 using the latest TestFlight version.

[nkaminski]

@cybercop23 When you say latest TestFlight version - are you referring to a later/TestFlight build of xLights than 2024.19?

[cybercop23]

Yes... I get interim updates with each commit. But nothing that would have broken or fixed this.

[nkaminski]

So another interesting datapoint: I have built the latest master branch of xLights from source and still do not have an operable show/hide display elements option.

Therefore, I tried setting a breakpoint at https://github.com/xLightsSequencer/xLights/blob/master/xLights/ViewsModelsPanel.cpp#L993 and it appears that I never hit this breakpoint therefore are we certain that the TestFlight version that you are using has been built against the exact same version and patchlevel of wxWidgets as version 2024.19?

[nkaminski]

OK, so after some analysis in the Xcode debugger, I finally understand in detail what's going on here:

The root of the issue appears to be the icon rect/bounding box size computation in wxWidgets at src/generic/listctrl.cpp:1750 computing a bounding box that is half the actual width and height of the icon on HiDPI displays.

Therefore, one can work around the issue by clicking within 8 pixels of the top left corner of the row containing the eye icon versus anywhere on the icon (highlighted in red in my image).

I'm not sure if disregarding the scale factor however is the appropriate solution to resolve this however.

[cybercop23]

Nice work. Pretty sure I was just clicking in the middle. What type of display do you have? Is it hi res/4k? Wonder if the ratio for that is off.

[nkaminski]

Can reproduce the behavior on:

• Internal display of my M3 MacBook Pro 16in
• External LG Ultrafine 5K display
• Internal display of the 2019 Intel MacBook Pro

All of these are ~200ppi displays, for which macOS is rendering at 2x scale.

What I think may be happening is wxWidgets is computing the bounding box in function HitTest() as icon_image_dimension / scale_factor instead of icon_image_dimension * scale_factor; as in its shrinking the rect used to test if a click is on the icon as opposed to growing it (as the icon image is 2x as many pixels wide and tall on HiDPI vs standard).