I'm seeing a few cosmetic issues...

• The smallest size of window being 320x200 is no coincidence, more like an easter egg, where I picked the Mode 13h dimensions as an interesting reference. But it's really arbitrary. So, the new minimums are 150x150 as requested.
• Another coincidence, I was already working on trying to get the icon to show into the caption (title bar). Not even reading my well-worn copy of Petzold several times seemed to help. foobar2000 doesn't make things easy, it took a while to reverse engineer what is happening. The key is that the title bar you and the context switcher sees is not the window the component is drawing into but a window that contains the component's main window.
• Back to the multi-monitor stuff. I don't know that I can do much here. See point 2. It might be an artifact from the outside window. Do you see the same in other visualizations? Maybe they have already solved this. However, I don't know exactly what you're seeing. Do you see the window "chrome" like it unmaximized inside the container? Or do you see a small (few pixels) border? If it is coming from the component, it would be cornflower blue because that's the color I paint the client area before rendering.

• Still some state memory is not cleared on component exit; likely one of the large string buffers in the State class. Not an outright leak though as the memory profile stays constant.
• Lots of unnecessary DirectX operations but no obvious references left unaccounted for on exit.
• There might still be some user interactivity hangs. The component will run for 10s of hours consecutively without issue (even when machine sleeps/hibernates) if just left doing its drawings.
• Icon to the foobar2000 window's menu/title bar propagates to unexpected places.
• Unexpected multimonitor behavior.
• Still have strobing effect in the composite shaders.
• Not all features fully tested.
• Surely some scenario in someone else's configuration/machine.
  
• Code handle pointer in texture manager invalid on window destroy.
• D3D11 WARNING: ID3D11DeviceContext::DrawIndexed: Index buffer has not enough space! [EXECUTION WARNING #359: DEVICE_DRAW_INDEX_BUFFER_TOO_SMALL]

Thanks...

Thanks for the update, but it takes a long time to start loading. Looking at the console, it takes at least 6 seconds.

After updating foo_vis_milk2, playing music will suddenly crash for an indeterminate amount of time, probably WebView related, my player never crashed before the update.

Thanks @oops
I also can confirm foobar crashes sometimes with the plug running, especially when a new track comes on.

Quote from: yeyo on 2024-09-09 05:31:31

Thanks for the update, but it takes a long time to start loading. Looking at the console, it takes at least 6 seconds.

I see something similar during cold starts of foobar2000. I think this is just the OS loading the app to RAM from disk. If I close after opening and shortly thereafter open again the entire app comes up "instantaneously." Let me know if you think I'm mistaken.

Quote from: yeyo on 2024-09-09 05:31:31

Thanks for the update, but it takes a long time to start loading. Looking at the console, it takes at least 6 seconds.

I see something similar during cold starts of foobar2000. I think this is just the OS loading the app to RAM from disk. If I close after opening and shortly thereafter open again the entire app comes up "instantaneously." Let me know if you think I'm mistaken.

I've fixed "WARNING #359: DEVICE_DRAW_INDEX_BUFFER_TOO_SMALL" message. It came from the title message that might come up during track change if you have that option set in this newer version. If you disable the "Show title anims. when song changes" option then that might avoid the crashing temporarily (until I roll out an update).
Another update in this version on track change is the loading of the album art. Try to disable this if you enabled it--if you right click make sure that "Show Album Art" is grayed out or does not have a tick mark.

Using foobar2000 2.1.5, with only the foo_vis_milk2 component installed in a fresh configuration, Whether it is a cold start or a hot start, the loading time takes 6s+, and changing the size of the FB window will cause the window to freeze for a certain time, and when you double-click the full screen, it will also cause a certain time of freezing, and it can easily cause a crash, the following is the crash report

Quote from: yeyo on 2024-09-11 02:34:55

Using foobar2000 2.1.5, with only the foo_vis_milk2 component installed in a fresh configuration, Whether it is a cold start or a hot start, the loading time takes 6s+, and changing the size of the FB window will cause the window to freeze for a certain time, and when you double-click the full screen, it will also cause a certain time of freezing, and it can easily cause a crash, the following is the crash report

Thanks, I took a look. It is indeed happening when drawing text on the screen. In this case, my suspicion is that the default fonts are not populated. If you bring up the font selection dialog from the preferences, these are the defaults. You could also try to hit the "Reset page" button to see if the configuration initializer reloads the defaults.

I'll investigate the stuttering and the startup performance.

This has been happening with the default settings. Now I can no longer access the sub-options of this visualization. Clicking it crashes immediately. Generated some new crash reports

• dmp3, dmp4 fixed, active playlist has 0 entries - Crash when pressing P or right click, fixed by adding size() check and returning "" if 0.
• dmp5 crashes/hangs on destroy window, either exiting or going fullscreen? Unclear why.
• dmp1, dmp2, dmp6 again crashes when trying to print screen message. Entire settings struct is zero'd out. Try to add some recovery by checking if default_szPluginsDirPath != settings.m_szPluginsDirPath and restore EVERYTHING to defaults on get_configuration().

Quote from: yeyo on 2024-09-12 02:26:08

This has been happening with the default settings. Now I can no longer access the sub-options of this visualization. Clicking it crashes immediately. Generated some new crash reports

My friend, your component installation is majorly borked. I don't know how. But the key is that your settings are all 0's. Since foobar2000 helpfully keeps what the initial value was into the config, I can tell they were overwritten at some point after initially setting them. Unsure how.
Your best bet on any of your installs is to uninstall and reinstall the component. If that doesn't work, try deleting the "config.sqlite" file (careful as this affects EVERYTHING in foobar2000). Or if you know what you're doing, using a tool such as DB Browser, you can surgically target the cfg_vars in "config.sqlite"; the GUIDs for each setting are listed here.
General advice (not implying you're doing this here): don't copy installs, use the installer. I have tried to reproduce this issue using Windows Sandbox without success. I cannot root cause what it is about your particular configuration that puts the component into this state.

Here are the quickie notes for the dumps:

• dmp3, dmp4 fixed, active playlist has 0 entries - Crash when pressing P or right click, fixed by adding size() check and returning "" if 0.
• dmp5 crashes/hangs on destroy window, either exiting or going fullscreen? Unclear why.
• dmp1, dmp2, dmp6 again crashes when trying to print screen message. Entire settings struct is zero'd out. Try to add some recovery by checking if default_szPluginsDirPath != settings.m_szPluginsDirPath and restore EVERYTHING to defaults on get_configuration().

Thank you for all you efforts in building this plugin.

Is it possible to have foo_vis_milk2 running full screen on 1 monitor while I'm using another monitor? Currently when I have foo_vis_milk2 running full screen on my left monitor, the instant I click anywhere on the right monitor it will jump out of full screen mode back to windowed.

I have also noticed that version 0.0.299-alpha crashes a lot for me, usually within the first few minutes of using it. Could it be that the preset\texture pack I'm using is too big (2.5GB+)?

The crash logs goes to the Foobar200 developer if i submit them, should I be attaching them in this thread instead?

Attached is a video of a fresh install crashing during operation test

The crash logs goes to the Foobar200 developer if i submit them, should I be attaching them in this thread instead?

Here are some crash logs from me.

• Some state memory is not cleared on component exit; likely one of the large string buffers in the State class. Not an outright leak though as the memory profile stays constant.
• Lots of unnecessary DirectX operations but no obvious references left unaccounted for on exit.
• There might still be some user interactivity hangs.
• Icon to the foobar2000 window's menu/title bar propagates to unexpected places.
• Unexpected multi-monitor/DPI behavior.
• Still have strobing effect at edges in the composite shaders.
• Code handle pointer in texture manager invalid on window destroy.
• D3D11 WARNING: ID3D11DeviceContext::DrawIndexed: Index buffer has not enough space! [EXECUTION WARNING #359: DEVICE_DRAW_INDEX_BUFFER_TOO_SMALL]

I published the first "beta" release last night: 0.1.0. Almost exclusively bug fixes. I'm hoping it addresses some of the crashes--some of you seem very adept at doing something to your graphics devices that cause the component to enter "device lost" mode