For Logic Pro, I run a large Floating Menu with around 140 buttons on a separate monitor. It only pops up when Logic is the frontmost app. Now when switching to Logic there has always been a little lag for the menu to build but it didn't hold up the workflow.
Now since 1-2 months the delay has increased to 1-2 secs and during that time, Logic is not responsive. In an attempt to decrease load of the menu I shrinked the buttons containing JPEGs (around 25 of them, the rest is text only) to around 20kb but that doesn’t seem to make a difference. Any ideas?
@HansW could you check whether 5.224 (uploading) improves things?
I think I didn't receive your menu yet (maybe it was too big to attach?) so I only tested with one of my menus.
This changes some bigger parts of the caching mechanism, it will need to be seen whether this breaks any existing behavior. If you find anything weird please let me know.
I'm happy to tell you that the new Alpha version works like a charm: my Floating Menu does appear almost instantaneous now, faster than ever. Thanks for the great support!
Hey @Andreas_Hegenberg, even with "Keep Menu in Cache" the sample floating menu I've shared here still takes around second or two to build up compared to almost instant build up when using the action "Show Floating WebView". What could be the reason?
Maybe I can make this default if the webview is added to a menu that has caching enabled. Unfortunately there are too many different usecases, and having the webview loaded in the background breaks many (e.g. not wanting to play music in background and similar), which is why this is off by default.
So you are saying that when "Keep Active in Background" is enabled it is expected to not clear the text field?
Is there a way to achieve this using the JS in the HTML or maybe using "User Script (On Becoming Visible)" ?
Correct that is expected with this option. However it is not expected that such a simple HTML could take so long to render. I wasn't able to reproduce that so far - it shows up immediately here, even without the caching options.
To reset the text field it would be most reliable to use the "Execute Java Script In Web View Menu Item" action like this:
Ah nice, this actions solves it, I've tried the same code inside the WebView config, but without success.
The menu I've provided is pretty much empty maybe this could be the reason? The real menu is a table with around 26 rows, and one of the columns is a URL.
that would only explain it if it would take the same amount of time with the old floating webview functionality (it’s basically the same code only little adjustments to make it work in swiftui)
I can confirm that with floating webview, if I check the "Do NOT keep content active in background (reduces memory usage, takes longer to show)" then the same behavior - it takes around 1sec to load the menu. However with the floating webview, even if this is unchecked, meaning the webview is active in background, there's no need for the JS you provided here.
