I made some tweaks to begin integrating baseview into iced_baseview.

• Added abstract Message structs.
• Added Receiver trait.
• Added compiler arguments for choosing between OpenGL and wgpu. (I haven't added any wgpu stuff yet).
• Refactored some of the code in x11/window.rs into x11/opengl_util.rs.
• Made x11/window.rs return Message messages to the Receiver.
• Updated example.

These changes are only tested in Linux.

I'm seeing issues with the rendering of a VST UI in Reaper on a Macbook with a Retina display.

This happens both with imgui-baseview and with egui-baseview.

Here's what happens with the Gain example from https://github.com/DGriffin91/imgui_baseview_test_vst2, for instance (this is Reaper's "FX Chain" UI btw):

The same thing happens with any other imgui or egui example. There is some rendering going on though: changing the clear_color of the window has effect, for instance. The only way I can fix this is by hard-coding the scale_factor of the window to 1.0 here. Supplying a WindowScalePolicy::ScaleFactor(1.0) in the WindowOpenOptions should do the same thing, but does not seem to have any effect.

If I manually double the window size in the example code here, then I do see the outlines of some UI being rendered, completely off-center and clipped:

Stepping through the baseview code, I do see that the logical size is the size that is being configured by me and the physical size is double that (since scale_factor is calculated to be 2.0). I am assuming the issue is not related specifically to either the imgui or egui renderers since they both exhibit the same behaviour. Additionally, running the imgui-baseview examples by themselves (i.e. outside of the VST host) works fine as well. So I'm a bit stumped on what the root cause could be.

I went to #xcb on Freenode and psychon was so kind to point me to: https://docs.rs/x11rb/0.8.0/x11rb/event_loop_integration/index.html

It seems that while events are being handled new events can be queued up in the internal buffers. And so the next poll() will wait even though there are still events to be handled.

This is a race condition, so that might be why this does only occur on some systems.

I am getting many (many) Unhandled event type: 65 prints when testing my GUI. That event number is way beyond the defined X11 events, and I guess it makes sense to just not print anything for these events for now.

hi! i made some changes so that raw_window_handle can be updated to 0.5.0 (this because im using it in conjunction with softbuffer for a personal project).

i only made the changes necessary for this pull request to work on macos since i don't have any access to another machine/os at the moment, but i'll leave this pr here in case there's initiative to update raw_window_handle in the future.

Adds handling of mouse scrolling using the mouse wheel or touch pad for macOS. Although basic event handling for macOS had been added before in #52, it looks to me like support for this was still missing. I had a look at all other public forks of this library and could not find someone working on this.

So I looked up the API documentation for it [1] and had a look at the existing code for mouse_move to make a change that feels consistent with the existing code. There seem to be two kinds of scroll delta values [2] [3] [4], precise and imprecise ones. I expect the precise deltas to be used when a touchpad is used and the imprecise ones if a mouse wheel is use. But I can only test the mouse wheel scenario, as I have a desktop computer and thus no touch pad to test with.

If this is something you'd like to merge, feel free to do so. If this code needs to be improved, give me feedback and I will try to address it or just make adjustments yourself. But if you have other plans and do not want to merge this, that's fine too.

[1] https://developer.apple.com/documentation/appkit/nsresponder/1534192-scrollwheel?language=objc [2] https://developer.apple.com/documentation/appkit/nsevent/1525758-hasprecisescrollingdeltas [3] https://developer.apple.com/documentation/appkit/nsevent/1524505-scrollingdeltax

To achieve lower input latency in iced, I need the frame interval to run at 120fps. Iced sets the wgpu swapchain to Mailbox mode, so rendering still happens at 60fps. However, this causes less misses for the current frame reducing the perceived latency.

This is a follow up to #115. Having the window own the context seemed like a sensible approach to me since there's an on_frame() callback where you'd do your rendering, but some integrations like @BillyDM's iced_baseview do the rendering from a separate Send + Sync + 'static context, and you thus need to be able to move the OpenGL context into there. This change means that you'll need to move the GlContext into your window handle struct when first creating it by calling window.gl_context().take().

This builds on top of #115, so I marked this as a draft until that has been merged.

Every mouse event now has a modifier field containing the current keyboard modifiers. Most window management APIs work like this, and it solves things like #116 by making sure that whenever a window receives a mouse event, it also knows the up to date keyboard modifier status.

As discussed on the Rust Audio Discord, this is necessary to be able to create an OpenGL context under X11. The OpenGL context configuration determines which framebuffer configuration should be used, but the framebuffer configuration in turn determines which visual should be used for the window the context will be used with. Because of that, it's not possible to create an OpenGL context for an X11 window after the fact. Because of that, the context creation from raw-gl-context's X11 module has now been split up into two parts: initializing the framebuffer config and determining a visual, and another one for actually creating the context after the window has been created. All of the other code from raw-gl-context is unchanged. The version of raw-gl-context used is from @prokopyl's PR adding more error checks on X11 (https://github.com/glowcoil/raw-gl-context/pull/15).

This is all put behind a new opengl feature that's disabled by default. The idea is that you can provide the OpenGL context options alongside the other window options, and if that's provided then calling window.gl_context() will return an Option<&GlContext> so you can access the OpenGL context in your window handler.

I've also taken the liberty to fix a lot of warnings. The main things remaining are a lot of unused cursor functions in the X11 implementation, and the immutable reference to mutable reference cast in the macOS implementation.

I've only tested this on Linux, so I would very much appreciate it if someone on macOS or Windows could test those implementations! On Linux it solves https://github.com/glowcoil/raw-gl-context/issues/2 for both NVIDIA drivers and Mesa, and for 0 and 8 bit alpha buffers. There's currently no example in the repo, but you can try this version of egui-baseview that's updated to work with these changes instead:

git clone https://github.com/robbert-vdh/egui-baseview.git -b fix/update-dependencies
cargo run --example simple_demo

This supersedes #114.

This was supposed to fix https://github.com/glowcoil/raw-gl-context/issues/2, but it seems like setting the correct visual wasn't the magic bullet. Still, having the windows created with a 32-bit visual seems like a good idea since almost everything does that and now you can rely on the baseview window always having the same depth instead of it being dependent on the parent window.

In order to use third party crates that, under the hood, may increase the ref count of the given NSView, we add an additional "window closing" check by querying the given NSView for its NSWindow parent, and subscribing to the NSWindowWillCloseNotification message.

Note that in DAWs such as Reaper, we share a parent window with other plugins, so this approach is not reliable (since you can switch between different plugins but the window persists). Those cases may require another solution.

(Mostly) fixes #124

I've implemented this for Linux back in March, and I only just added Windows support. Still need to add macOS support, but I thought I'd submit a draft PR already because the changes needed for Windows support are pretty invasive. So we may want to discuss the best course of action first.

Resizing the window sends a WM_SIZE event and a couple other events to the window, so the window procedure and WindowState had to be changed to use interior mutability everywhere instead of wrapping the entire struct in a RefCell. This resolves most of the reentrant event call concerns from #130, but I'm not sure if it also prevents panics in that specific example To make this work there's now a deferred_tasks queue for handling tasks that are the result of a call to one of the Window methods in an event handler that may also indirectly emit other events. Perhaps Window::close() should also be implemented this way.

The Linux implementation was extremely straightforward, and I'll get to the macOS one next.

This closes #121.

Explanation:

• Reentering wnd_proc can happen, e.g. when opening the system web browser in an event handler via webbrowser crate.
• That's why this PR uses try_borrow_mut to fall back to the default window procedure if wnd_proc is reentered.
• I didn't convert each borrow_mut to try_borrow_mut, just the ones necessary to make the webbrowser crate work, see this PR for egui-baseview: https://github.com/BillyDM/egui-baseview/pull/12.

When embedding a baseview window inside another window using the open_parented() function on macOS, the first click on the window only focuses the window and doesn't trigger a mouse button down event for the window handler. Additionally, after this first click the user needs to wiggle their mouse around a bit because up until that point no mouse movement event will have been sent to the window. The view overrides the acceptsFirstMouse method, but it never seems to be fired. And the tracking areas should allow the plugin to receive mouse movement updates when the user hovers over an unfocused baseview window but that also doesn't seem to work.

I tested this on macOS Catalina with the NIH-plug plugins and OctaSine, and also with the NIH-plug standalones which embed a baseview window inside of another blocking baseview window.