[v1a9] Target color setting very slow to update

[archetyped]

Changing the target color setting in the preferences (v1a9) is causes Wooshy to hang for 10+ seconds before the setting is updated.

This makes the "Hue" slider is basically unusable because it gets locked up for 10+ seconds whenever the mouse drag begins.

[godbout]

well it needs to calculate live the targets the first time you touch the slide, but it should take 20 to 50ms depending on the number of Targets you have. 10+ seconds that's kinda crazy. can you take a video and show me what it targets? thanks.

[godbout]

here's how it works here:

ScreenFlow.mp4

[godbout]

if you move the slider fast at first there's a slight delay because it's grabbing the Targets. but definitely shouldn't be 10+ seconds 😂️ i'm experimenting with loading the Targets only once when you enter the Tab, but this causes other issues. like if you move the Settings window, all the Targets will be out of place. this is currently the best balance i've found.

[godbout]

tried both on Ventura public beta 2, and Monterey 12.5. all good.

so please:

1. try taking a video of your full screen showing the issue
2. try restarting the app
3. try rebooting

thanks.

[archetyped]

Wooshy_1a9_Prefs_Looks_Target-color.mov

[godbout]

so please:

1. try taking a video of your full screen showing the issue

full screen, thanks. i need to see what Wooshy is targeting.

2. try restarting the app
3. try rebooting

can you do that and let me know if it helps? thanks. else i can't follow up on this issue.

[godbout]

@archetyped still the case?

[archetyped]

Yes, Wooshy 1a18 hangs for about 7 seconds after the Color setting is changed. Interestingly, there is no hanging or delay when the custom option is selected. All targets are highlighted immediately and the color changing is responsive.

The video below was recorded after rebooting the computer and restarting the app:

Wooshy_1a18_Prefs_Looks_Target-color.mp4

[godbout]

yeah the custom and the others are handled differently. i had tried to do something smoother but the result was quite inconsistent. but it's still plain weird. what Wooshy does when you choose a Target Color is just running like if you were activating manually. when you use Wooshy itself you don't have this slowdown right?

[godbout]

this is the result here, which is what is expected:

ScreenFlow.mp4

it's just running Wooshy against the current Settings window, which doesn't have much UI Elements, so it's supposed to be pretty fast.

will try on Monterey again, but i think i did before and it was fine.

[godbout]

interesting. i was able to reproduce it once under Monterey, after two minutes trying:

ScreenFlow.mp4

not sure if it's related to your case as it seems in your case it's happening all the time. but i'll have a look.

[archetyped]

yeah the custom and the others are handled differently.

Just in case it helps narrow down the issue, I noted the responsiveness was different between custom and the other color modes because original, custom had the same slow response (see original video), but after the next (or next next) update, custom was smooth and responsive.

when you use Wooshy itself you don't have this slowdown right?

No slowdown when activating Wooshy in normal use, in any of the color modes.

not sure if it's related to your case as it seems in your case it's happening all the time.

Yes, the hanging is consistently occurring.

[archetyped]

I systematically closed out the apps that displayed menu bar icons to see if that had any effect.

There were two apps that had an effect on Wooshy hanging when changing the color mode:

1. Hammerspoon
2. PhraseExpress

If either app displayed an icon in the menu bar, Wooshy would hang when changing the color mode.
Once both app icons were removed from the menu bar, changing Wooshy's color mode was responsive.

Note: Even hiding the icons using a menu bar cleanup app (I'm using Hidden Bar) prevented Wooshy from hanging when changing the color mode. Unfortunately, hiding PhraseExpress' menu bar icon affects its functionality (its popup menu is normally displayed at the icon's location, but not when it is hidden).

[godbout]

Just in case it helps narrow down the issue, I noted the responsiveness was different between custom and the other color modes because original, custom had the same slow response (see original video), but after the next (or next next) update, custom was smooth and responsive.

yeah, coz i've changed the way the hue works. because you need constant update when playing with the slider, the stuff happens on a background thread. but not for the other 3 settings, because else they're missing UI elements and the UX is inconsistent. shouldn't usually be a problem because gathering the info should be fast, but in your case it's not, hence the hanging.

No slowdown when activating Wooshy in normal use, in any of the color modes.

that's just bizarre 😂️

[godbout]

I systematically closed out the apps that displayed menu bar icons to see if that had any effect.

There were two apps that had an effect on Wooshy hanging when changing the color mode:

1. Hammerspoon
2. PhraseExpress

If either app displayed an icon in the menu bar, Wooshy would hang when changing the color mode. Once both app icons were removed from the menu bar, changing Wooshy's color mode was responsive.

ah, nice, you beat me to it. i wondered and was gonna asked, but i saw (thought) too that you were using Bartender or something similar, and Wooshy wouldn't get the elements for those hidden icons, so i thought it may not matter. my bad.

i don't remember seeing any issue with the few times i had Hammerspoon running, but i'll check again with both. thanks.

[godbout]

ok so i've check with both apps.

1. in my case, HS doesn't affect anything. maybe it's your config? i wouldn't see why tho. care to share it?
2. PhraseExpress slows down yeah. i went through the installation and honestly, it doesn't really inspire confidence. looks like a bad probably Java app? the status bar menu... definitely not native. my guess is that in your case you have a lot of stuff in the Clipboard Cache and/or Last Used and it's done badly and slowly, so Wooshy is hanging while getting that data. (why it doesn't happen when you use Wooshy in normal time, i don't know yet.) care to share how many items you have?

in my case also just launching the app hangs my computer.

i'll see what i can do. but ultimately 1) i don't think this is a big issue as it's an edge case and happening only when you're in the Settings it seems 2) i'm not gonna go too much out of my way to support app that are really not standard. Wooshy has to use specific macOS APIs and if apps wanna do funky stuff and respect nothing, it's on them.

for reference:

ScreenFlow.mp4

[godbout]

can you try a20? https://github.com/godbout/Wooshy.docs/releases/tag/1.a20

forgot to put in the release notes but there's tweaks for this. it should/may still take a lot of time in your case, but it shouldn't hang anymore.

[archetyped]

can you try a20?

No noticeable differences with v1a20.

PhraseExpress slows down yeah [...] my guess is that in your case you have a lot of stuff in the Clipboard Cache and/or Last Used and it's done badly and slowly

Clipboard Cache and Last Used features are disabled via PhraseExpress' settings.

---

After more testing, the hanging in Wooshy's preferences appears to be related to the use of window filters in Hammerspoon-- specifically subscribing to window events.

This can be consistently reproduced by adding the following Lua snippet to Hammerspoon's init file:

-- Test: Window Filter

-- Init window filter
local wf = hs.window.filter

-- Subscribe to app focus/unfocus events
wf.new("Safari")
    :subscribe(wf.windowFocused, function ()
        print('Safari focused')
    end)

Note that the window filter is not set to monitor Wooshy's window events. Simply monitoring window events for any app appears to cause a lag in Wooshy's color preferences. I would guess that something similar is going on in PhraseExpress, as it can enable/disable functionality based on the focused app.

I understand not spending too much time debugging this issue. I'm just reporting issues as I find them as a dutiful alpha tester 😉 Though, as the issue appears to be related to apps monitoring window events, it may rear its head again in other areas, as these aren't the only two apps to do such things.

[godbout]

No noticeable differences with v1a20.

wow. at least i would have expected the hanging to stop, as grabbing the UI Elements is now done in the background (but the UI update is in the foreground, so worst case is you wouldn't have seen the UI refreshed right away). weird.

Clipboard Cache and Last Used features are disabled via PhraseExpress' settings.

After more testing, the hanging in Wooshy's preferences appears to be related to the use of window filters in Hammerspoon-- specifically subscribing to window events.

This can be consistently reproduced by adding the following Lua snippet to Hammerspoon's init file:

-- Test: Window Filter

-- Init window filter
local wf = hs.window.filter

-- Subscribe to app focus/unfocus events
wf.new("Safari")
    :subscribe(wf.windowFocused, function ()
        print('Safari focused')
    end)

Note that the window filter is not set to monitor Wooshy's window events. Simply monitoring window events for any app appears to cause a lag in Wooshy's color preferences. I would guess that something similar is going on in PhraseExpress, as it can enable/disable functionality based on the focused app.

good, thanks for the precision.
hmm yeah, maybe. never had any issue myself with some other apps that for sure are using similar technology like HazeOver. also no report. also strange that it happens only when dealing with that part of the Preferences.

I understand not spending too much time debugging this issue. I'm just reporting issues as I find them as a dutiful alpha tester 😉 Though, as the issue appears to be related to apps monitoring window events, it may rear its head again in other areas, as these aren't the only two apps to do such things.

thanks yeah. i don't think it's a big issue if it stays in the Preferences, but my personal issue currently is that i don't understand what's happening. so i'm gonna have to find out first, and then decide if it's worth fixing or not. BUT I NEED TO KNOW!!! 😂️

[godbout]

@archetyped are you still seeing the issue? can't on at least Sequoia.

[godbout]

no answer. can't reproduce. closing.