bevy_egui feature does not work correctly with bevy_egui 0.24.0

[brookman]

It seems the focus handling does not work correctly anymore together with bevy_egui 0.24.0 (tested with bevy_panorbit_camera = { version = "0.9.2", features = ["bevy_egui"] })

Inputs on top of egui windows still cause the camera to move/rotate/zoom. With bevy_egui 0.23.0 drag and rotate events at least were not passing through. Mouse scroll events on Windows were kind of broken with 0.23.0 already: When scrolling on top of the menu the scroll events where buffered and applied (as zoom) when the mouse left the menu.

[Plonq]

Hi thanks for letting me know, I'll look into this soon

[Plonq]

An update.

Addressing bevy_egui 0.24 - I noticed that bevy-inspector-egui 0.21 (latest) doesn't support egui 0.24 (and therefore bevy_egui 0.24) yet. The issue being that if you have mut contexts: bevy_egui::EguiContexts in a system, it panics about not being able to find EguiUserTextures. It works if I use bevy_egui directly without bevy-inspector-egui, but I was having other issues with the egui window not working properly, which I have yet to solve. Regardless, I'll probably wait for bevy-inspector-egui to update before releasing a new version depending on bevy_egui 0.24.

Addressing the issue on Windows - after testing, this seems to be unavoidable. I get a similar issue on MacOS when I'm using smooth scrolling software. The issue is that scrolling doesn't actually stop when you stop using the mouse wheel - scroll events keep getting sent to the app under the cursor, in order to get that smooth deceleration effect. If you leave your mouse over the egui window for longer after stopping scrolling, then move it off, nothing will happen.
So long story short, there's no way to fix this that I know of.

[brookman]

Thanks for the feedback.
Regarding the scroll issue on Windows: For me it doesn't matter however long I wait after scrolling on the egui window before moving the mouse to the 3d scene. The 3d scene zooms even after waiting for 30s or more.

[Plonq]

Thanks for the feedback. Regarding the scroll issue on Windows: For me it doesn't matter however long I wait after scrolling on the egui window before moving the mouse to the 3d scene. The 3d scene zooms even after waiting for 30s or more.

That's very strange. I can try to take another look, but I suspect the problem lies outside of anything this plugin has control over. In other words, if bevy/winit continues to receive scroll events after moving the mouse outside of the egui window, even when you've stopped scrolling, then there's no way for this plugin to differentiate them from real events. On the other hand, if this 'buffering' of scroll events is somehow happening inside bevy/egui, then there's possibly a solution, but I don't think this case is likely.

[Plonq]

I've updated master branch to use bevy_egui 0.24, however it won't work with bevy-inspector-egui (0.21) as that hasn't been updated yet. Therefore, I won't release a new version just yet, but you can depend on master in the meantime.

Edit: i.e. waiting for jakobhellermann/bevy-inspector-egui#174

[Plonq]

I changed my mind - no need to wait. 0.10.0 published. jakobhellermann/bevy-inspector-egui#174 doesn't look like it's far from being merged anyway.

[Plonq]

@brookman I believe the scroll issue you mention is actually caused by the issue described here: https://bevyengine.org/news/bevy-0-13/#events-live-longer

My testing shows that the workaround mentioned there fixes the problem:

app.world.remove_resource::<EventUpdateSignal>();

BEFORE:

before.mov

AFTER: (note: the slight movement shown here is due to me using scroll smoothing software)

Screen.Recording.2024-02-18.at.6.19.58.pm.mov

[SK83RJOSH]

I just want to say that this is still present in bevy 13.2, and the proposed workaround does not work:

jc2_tools_JR1zHAygC6.mp4

I suspect that the bevy issue that was mentioned is/was not the root cause, as the following fixes the issue:

.add_systems(
    PreUpdate,
    (draw_egui).after(EguiSet::BeginFrame),
)

Which leads me to suspect this issue occurs depending on whether or not your UI gets scheduled before or after egui::check_egui_wants_focus.

I think it would be wise for bevy_panorbit_camera to expose an PanOrbitCameraEguiSystemSet to schedule against, and to mention it in the docs.

It might also make sense to try to use PostUpdate instead for the PanOrbitCameraSystemSet which would largely eliminate the need for the extra set - but it could still be needed in some scenarios.

[Plonq]

@SK83RJOSH the problem you describe is unrelated to this issue, but it is a problem. I'll get to this soon, thanks for reporting.

[Plonq]

@SK83RJOSH Can you provide a minimal repro? I haven't been able to reproduce what you show in the video, even after creating a system set like you suggest and then scheduling the GUI system after it. And can you create a new issue please?

[SK83RJOSH]

@Plonq sure thing! Likely won't be able to get around to it until this weekend though, as I'm bedridden at the moment. In the meantime, the specifics of that setup were:

1. One system running in Update while pinned to the main thread using _windows: NonSend<WinitWindows> rendering the title bar
2. Another system scheduled after that, rendering the file tree

Since you're unable to reproduce, I suspect the main thread requirement might be at play some how? Might be useful for you to triage at least.

You can also find the associated code here if you want to investigate further in the meantime (remove the set requirement, and copy those systems to a test app and I think you'll be able to repro).