usage with rust-vst, UI is not painted

[WeirdConstructor]

I don't know if this is actually an issue with this crate. But I somehow can't get pugl to work as expected.

I set up everything to best of my knowledge over in my project, here is the complete GUI code so far: https://github.com/WeirdConstructor/Kickmess/blob/master/src/editor.rs

My observations so far:

• the idle() method is properly called and it calls the pugl update() method. it does not return an error.
• open() is properly called and everything is setup without returning errors.
• the exposed() method is called, and should draw something with cairo.
• event() is not called by pugl, and no events are received
• resize() is not called by pugl
• The window stays unpainted (seemingly transparent, with old pixels from memory), see screenshot:

Maybe I am doing something wrong. But I fail to see what so far, maybe someone has an insight in what might be the problem?

system specs:

• Ubuntu 18
• Carla as host for the VST plugin (DSP code runs fine)
• Other OpenGL applications run fine (=> nvidia drivers are setup correctly)

[johannes-mueller]

Thanks for reporting.

I tried to reproduce it. Here is what I observe.

The window seems to be drawn, at least what I see seems to correspond to your exposed() code.

In the carla logs I see stuff like this

update: Success
update: Success
update: Success
update: Success
update: Success
update: Success
EVENT!
MOUSEMOVE: 140:31
EXPOSED
update: Success
EVENT!
MOUSEMOVE: 137:34
EXPOSED
update: Success
EVENT!
MOUSEMOVE: 134:35

So the event handler function seems to be called.

The system here is an Arch system, also carla (version 2.2.0) as host. I only changed the relative crate paths in your Cargo.toml make it build. Everything else I left untouched.

So probably nothing wrong with your code.

Can you test the demo test in pugl-sys, please? Just clone pugl-sys and run cargo test --doc -- --ignored. It should draw a blue rectangle with a red circle in it. When you move the mouse in the window the color of the circle changes. If that does not work, you could try to build and run the examples of pugl to see if they work. That would require some effort, though.

[WeirdConstructor]

I just instrumented pugl-sys, and got this output when running from Ardour:

OPEN null=false
puglNEWNEWNEWNEWNEWN
puglSetParentWindow done!
puglView::new done!
SET WINDOW TITLE: Kickmess
title: Success
set_default_size: Success
event_handler: 1
show_window: Success
OPENED
update: Success
event_handler: 3
RESIZE
event_handler: 4
event_handler: 0
event_handler: 7
EXPOSED
update: Success
....

The last received event is the exposed event.

The test you showed works fine.

[WeirdConstructor]

pugl examples all run well as it seems. I also use carla 2.2.0. This is really weird.

[WeirdConstructor]

I have no idea how deep I am into the rabbit hole, but as far as I see, when cairo_xlib_surface_create() is called, the given surface size is 0x0 big. It seems, as if the PUGL_CONFIGURE event is never triggered. This is already deep down into the guts of pugl itself and probably not a matter of this crate.

It seems as if the last proper X event is the VisibilityNotify. And there is no ConfigureNotify event or Expose event from X before the cairo surface is created. Maybe pugl is doing something that does not work on my system.

[johannes-mueller]

I did some more tests:

• run Kickmess in carla on an Ubuntu 20 system (carla 2.1.0) → behavior as you describe, no event after first expose
• run Kickmess in ardour: panics when trying to unwrap() in Editor::idle()
• my envolvigo lv2 plugin also does not receive events in carla 2.1.0 on Ubuntu, not tested on Arch yet.
• envolvigo in ardour works.

However envolvigo uses an older version of pugl-sys. I will update envolvigo to use the current pugl-sys and then test again.

[WeirdConstructor]

I fixed the unwrap() in the current version. I was debugging with drobilla on IRC - if there is maybe something wrong with pugl.

[WeirdConstructor]

The debugging is inconclusive so far. I would love some dummy lv2 or vst plugin that uses pugl directly without the Rust bindings - to make things simpler.

However, as drobilla said, the fact no mouse events are received points to embedded window handling shenanigans.

Also good that you can reproduce the issue.

I could unfortunately not build envolvigo:

    Updating git repository `https://github.com/johannes-mueller/rust-lv2.git`
    Updating crates.io index
    Updating git repository `https://github.com/johannes-mueller/jilar.git`
error: failed to select a version for `clang-sys`.
    ... required by package `bindgen v0.54.0`
    ... which is depended on by `pugl-sys v0.3.3`
    ... which is depended on by `envolvigo-lv2-ui v0.0.1 (/home/weictr/devel/rust/other/envolvigo/ui)`
versions that meet the requirements `^0.29` are: 0.29.3, 0.29.2, 0.29.1, 0.29.0

the package `clang-sys` links to the native library `clang`, but it conflicts with a previous package which links to `clang` as well:
package `clang-sys v1.0.0`
    ... which is depended on by `bindgen v0.55.1`
    ... which is depended on by `pugl-sys v0.4.0`
    ... which is depended on by `jilar v0.1.0 (https://github.com/johannes-mueller/jilar.git#930df368)`
    ... which is depended on by `envolvigo-lv2-ui v0.0.1 (/home/weictr/devel/rust/other/envolvigo/ui)`

failed to select a version for `clang-sys` which could resolve this conflict

[johannes-mueller]

For now you still need clang installed to build envolvigo AFAIK. This has been solved in rust-lv2 0.6.0. I will need to do some work to update my lv2-ui branch to that and then envolvigo. Maybe I can then also write some amp ui hello world plugin using the rust-lv2/pugl-sys stack. I can't promise when I will have that ready, though.

[johannes-mueller]

Another screenshot using Ardour on Arch. Events also get processed. The window is also resizable.

[WeirdConstructor]

For reference, I opened up an issue over at pugl's repository at gitlab, with a further investigation of the X11 events behind the hood:

https://gitlab.com/lv2/pugl/-/issues/15

[WeirdConstructor]

I also tried using SDL2 by now. No idea if I am doing something wrong, because I get the exact same results: No painted window. Put the code into an extra branch: https://github.com/WeirdConstructor/Kickmess/tree/sdl2_test

[WeirdConstructor]

Today I tried the baseview crate, to check if I have the same problem with it. It does not handle X11 via XLib like pugl does, but it uses the XCB bindings. There is a simple test for receiving X11 events at https://github.com/greatest-ape/baseview_test_vst2 and it worked right out of the box. I got a log file with X11 events on my system, with Carla and with Ardour.

I might try to hook up a cairo surface to that and check if I can get some pixels and events going.

[WeirdConstructor]

I investigated further today. It seems that pugl is currently not a viable option for VST plugins. See here for a detailed explanation: https://gitlab.com/lv2/pugl/-/issues/15#note_452099345

~~In short: VST hosts read the X11 events before the plugin receives them. JUCE does some X11 root window hacks for receiving events. And pugl relies on XNextEvent() to get the next event, which never comes, because the host reads all events and wants to transmit them to the plugin via a callback the VST plugin has to register as XWindowProperty called _XEventProc.~~

[johannes-mueller]

Hmm, but then why does it seem to work here, on Arch/Ardour6, Arch/Carla 2.2.0, Ubuntu 20/Ardour6? The only combination that doesn't is Ubuntu 20/Carla 2.2.0, but that could well be a problem with pugl-sys, because also Envolvigo does not work there. However, that could well be an issue further down the road in my rust-lv2 branch, in pugl-ui, jilar or the plugin itself.

In the meantime I updated Envolvigo. It should now build again.

[WeirdConstructor]

Sadly I still don't understand why pugl does not work and baseview does and I misunderstood the X server event propagation somewhat.

[WeirdConstructor]

I finally found it. I analyzed the X window tree and saw that the new "Pugl" window is way outside the parent window of the Host: xwininfo -root -all | grep -C 5 -i \"pugl\"

     0x40f7e5 (has no name): ()  400x430+738+536  +738+536
        1 child:
        0x4600001 "Kickmess (VST) (GUI)": ()  400x400+0+30  +738+566
           1 child:
           0x4800004 (has no name): ("Pugl" "Pugl")  900x400+1470+340  +2208+906

pugl currently sets the x and y position of the newly created plugin window to something around the screen center. but the x and y position are relative to the host plugin window, so the new window is outside of everything and does not receive any input events (mouse or keyboard). I forced proper placement with this:

        let mut view =
            PuglView::<KickmessUI>::new(
                parent,
                |pv| KickmessUI::new(pv));

        let ui = view.handle();
        ui.set_frame(Rect {
            pos: Coord { x: 0., y: 0. },
            size: Size { w: 900., h: 900. },
        });

I'll talk to the pugl author whether the set_frame is really required, even though I do set_default_size.

[johannes-mueller]

Glad you found a way to make it work. However, the question remains, why it worked here on my setup. Maybe it depends on the window manager? I am using kwin.

What window manager / desktop environment are you using? I'd like to do some tests with that one.

[WeirdConstructor]

I used i3wm first and now I am on Ubuntu 18 standard window manager. I have no clue why it would work for you in one case. I guess the initial screen position of the DAW and the initial plugin window might play a role.

This was the C pugl code that set x and y:

        view->frame.x      = screenWidth / 2.0 - view->frame.width / 2.0;
        view->frame.y      = screenHeight / 2.0 - view->frame.height / 2.0;

But as you saw on IRC, drobilla already committed a fix for this case as it seems.

[WeirdConstructor]

The upstream commit https://gitlab.com/lv2/pugl/-/commit/0a5b734f6d373b5230d79db625ca311255a49abf should fix this.

[johannes-mueller]

Upstream pugl updated in release 0.4.1

Thx