#266 (Windows Thread-based DPI awareness) causes Ableton to crash

[AlexCharlton]

#266 has resulted in the opening of a baseview window in Ableton to crash. The same plugin built with baseview prior to #266 is able to open with no issues.

The crash is caused by a panic: thread 'unnamed' panicked at 'RefCell already borrowed': C:\programming\external\baseview\src\win\window.rs:526, which corresponds to handle_event calling self.handler.borrow_mut.

It seems that Ableton triggers a number of events while opening the window:

13:54:44 [INFO] baseview::win::window: handle_event call site: WM_MOUSEMOVE CursorEntered
13:54:44 [INFO] baseview::win::window: handle_event call site: WM_MOUSEMOVE CursorMoved
13:54:44 [INFO] baseview::win::window: handle_event call site: WM_SETFOCUS Focused
13:54:44 [INFO] baseview::win::window: handle_event call site: WM_*BUTTON* ButtonReleased { button: Left, modifiers: NUM_LOCK }
13:54:44 [INFO] baseview::win::window: handle_event call site: WM_MOUSEMOVE CursorMoved
13:54:44 [INFO] baseview::win::window: handle_event call site: WM_SIZE Resized
13:54:44 [ERROR] nice_plug::wrapper::util: thread 'unnamed' panicked at 'RefCell already borrowed': C:\programming\external\baseview\src\win\window.rs:526

The panic can be avoided by calling try_borrow_mut:

pub(crate) fn handle_event(&self, event: Event) -> EventStatus {
        let Ok(mut handler) = self.handler.try_borrow_mut() else {
            return EventStatus::Ignored;
        };

        let Some(handler) = handler.as_mut() else {
            return EventStatus::Ignored;
        };

        let mut window = crate::window::Window::new(Window { state: self });
        handler.on_event(&mut window, event)
    }

But this of course causes the event to be ignored.

[AlexCharlton]

I've discovered an interesting wrinkle here: This crash occurred prior to #266 if "Auto scale plugin window" is de-selected for the plugin (it's enabled by default). When "Auto scale plugin window" (ASPW from now on) is selected, the windows that are created are universally not DPI aware and are opened with a pre-scaled window size.

This try_borrow_mut fix prevents a crash in either ASPW mode, of course, but when ASPW is de-selected the window does not get scaled correctly. The baseview application still receives a resize event with the correct size, however, so skipping the on_event doesn't seem to have a negative affect in this case.

[AlexCharlton]

Based on the ASPW-related link above, I suspect the incorrect window size is due to nice-plug not knowing how to resize VST3 windows. In other words, baseview is probably not at fault for this.

Edit: Confirmed that I can get a correctly-sized window with the right DPI by hacking nice-plug, though I probably could have just used a version of it that included https://codeberg.org/RustAudio/nice-plug/pulls/48

[prokopyl]

Ah, yeah I see what's going on. Indeed you can nudge the host into making a sequence of events that doesn't crash baseview, but it's still the one that's crashing due to reentrant events.

I think #267 should help with this (although it and all of the next branch are full of breaking changes, so it's hard to just switch to it for testing)

[prokopyl]

I have just updated egui-baseview to the latest next branch commit here: https://codeberg.org/RustAudio/egui-baseview/pulls/31

If your plugin uses egui, perhaps you could patch it to try it using the latest baseview that way?

[AlexCharlton]

I don't use egui, but I got my test plugin working with the next branch and I can confirm that this is no longer an issue on that branch!