Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ndk-glue does not handle NativeWindow lifecycle correctly #117

Closed
maciejgodek opened this issue Jan 24, 2021 · 16 comments · Fixed by #134
Closed

ndk-glue does not handle NativeWindow lifecycle correctly #117

maciejgodek opened this issue Jan 24, 2021 · 16 comments · Fixed by #134

Comments

@maciejgodek
Copy link
Contributor

maciejgodek commented Jan 24, 2021

As far as I understand, ndk-glue's NativeActivity callbacks make it impossible or at least very hard to handle the NativeWindow lifecycle in a manner that conforms with the Android documentation. The chief offending callback is on_window_destroyed.

ANativeActivityCallbacks documentation seems to demand that NativeWindow cleanup code be executed in a synchronized manner, i.e. before the callback returns. For example, one might wish to ensure OpenGL is done drawing and destroy the associated EGLSurface.

NDK android_native_app_glue appears to follow this guideline, cf. especially how lifecycle event handling is split into pre-user-callback and post-user-callback parts (lines 89 and 146 respectively).

EDIT: for added context, compare example usage of NDK android_native_app_glue feature.

@MarijnS95
Copy link
Member

MarijnS95 commented Jan 24, 2021

Correct!

I think the most interesting lines are 306-308 though, showing that android_app_set_window (called from onNativeWindowDestroyed) indeed blocks and waits until the application thread processed the destroy message (android_app_post_exec_cmd indeed).

At the same time it seems unfair to pull NATIVE_WINDOW from under the application, native_window() would panic in that case.

I've been thinking about fixing this before, and it probably comes down to delivering this event to the application in a different way that allows us to make sure their cleanup handler has ran, surrounded by similar synchronization primitives.

@MarijnS95
Copy link
Member

Interesting to note that their on_window_created handler first checks if the previous window was cleaned up, and sends a destroy message for it otherwise.

@maciejgodek
Copy link
Contributor Author

Thanks for the quick confirmation! I'd love to try to put a pull request together, but: I'm pretty new at Rust, and as you say, it would be necessary to come up with better synchronization with user code, impacting e.g. winit. I'd probably need a fair amount of hand-holding.

@maciejgodek
Copy link
Contributor Author

maciejgodek commented Jan 24, 2021

Interesting to note that their on_window_created handler first checks if the previous window was cleaned up, and sends a destroy message for it otherwise.

I'm not sure that's the case. It seems that the function android_app_set_window() just gets reused in onNativeWindowCreated and onNativeWindowDestroyed (with NULL pointer argument). It relies on some undocumented invariants (especially on the value of android_app->pendingWindow) to do the right thing. It's just unnecessarily dense code.

However this code seems to ensure that if onNativeWindowDestroyed fires before the user event loop has processed the INIT_WINDOW message, the window is preemptively NULLed out and won't be used or drawn to at all. (This requires a NULL check on the user side.) It seems to mostly be an optimization, so as to ensure no expensive and useless drawing path is run while the NativeActivity loop waits inside onNativeWindowDestroyed.

@maciejgodek
Copy link
Contributor Author

maciejgodek commented Jan 24, 2021

As far as solutions for ndk-glue go — assuming there is no actual black magic involved: might it not suffice to add a one-shot channel / fence of some kind that user code must notify when done with NativeWindow cleanup? There are actually only two types of events that need this kind of synchronization (on_window_destroyed and on_save_instance_state, which is currently unimplemented anyway), so it seems like a simple hack might be enough?

@MarijnS95
Copy link
Member

@maciejgodek Correct, in hindsight it seems more of a simplification than an actual paranoid attempt to make sure no window is leaked. For the same reasons I'd either like to see the same behaviour (clean up the window if non-null before assigning), or an assertion.

No matter the implementation it seems like onInputQueueDestroyed and onNativeWindowRedrawNeeded need synchronization as well; we might want to spend some time flushing out a high-level representation of these rather than applying a simple hack. I don't want to restrict API users too much; at the same time I don't want an application to deadlock because someone forgot to signal ndk-glue that one of the few "synchronous" events has been processed. That usually ends in some closure running within some locked context, though.

@maciejgodek
Copy link
Contributor Author

maciejgodek commented Feb 3, 2021

It took me an evening or three to get a minimal "hello triangle" app running on Android to have a basic debugging environment & get a better handle on EGL behavior. (I hacked bits of glutin together with glow-rs.) I can now try to implement your suggestion, should have something to share in a few days.

I'm going to give up on the UNIX pipe of single byte enums as event queue. Instead I suggest a queue of Rust enums, much like what winit uses for user events. For events providing a new resource and/or requiring synchronization with the callback, the enum variant will contain a SyncEventContext, something along the lines of:

pub struct SyncEventContext<T> {
    done_notifier: Sender<()>,
    payload: Arc<Mutex<T>> 
}

impl<T> SyncEventContext<T> {
    pub fn handle<F: FnOnce(&T)>(self, f: F) {
        {
            let lock = self.payload.lock().unwrap();
            f(&lock);
        }
        let _ = self.done_notifier.send(());
    }
}

Any thoughts?

@MarijnS95
Copy link
Member

@maciejgodek The advantage of the pipe is that can easily integrate with Androids Looper, immediately making the source clear. With this approach you'll need to .wake() the Looper and figure out where that wake came from; similar to the issue discussed in rust-windowing/winit#1822 (comment).

At this point we should probably create a higher-level wrapper in ndk-glue around .wake() and retrieving event source + possible extra data, taking generics that can be passed through an atomic queue or channel.

Otherwise these events might be triggered by a single-byte write on the original UNIX pipe (or a new one with distinct ident) in the form of a new Event::SyncEvent that the consumer should retrieve/process from that queue. From an ndk-glue perspective that could be wrapped in a struct that signals done_notifier when dropped. You could possibly mix the Mutex with a Condvar to achieve this.

@maciejgodek
Copy link
Contributor Author

maciejgodek commented Feb 5, 2021

Both options make sense. I think I prefer the first one.

Here's what I've been thinking though: all you need to plug into the Looper is a file descriptor that can be slept on/polled, right? I thought we could build a higher-level generic event source around eventfd instead of pipe. As for event storage, you could use Arc<Mutex<VecDeque>> to start with and then maybe something cleverer / more tightly integrated with the waking mechanism. For example a lockless queue if a suitable implementation can be found.

@maciejgodek
Copy link
Contributor Author

maciejgodek commented Feb 9, 2021

I've put together something matching the above description in PR #121. Not sure if it's changing too much in the API. I also accidentally added a new method of building another event queue attached to the looper (e.g. user event queue in winit) and a method of sending redraw events.

I've got a rough winit branch that works with this API, will push my fork tomorrow. I might try to adapt glutin for it next week.

@dvc94ch
Copy link
Contributor

dvc94ch commented Feb 10, 2021

Why is there a problem? native_window returns a guard and on_window_destroyed takes a write lock, which will block until all read locks are dropped.

I think the problem is with glutin when trying to write correct code (no one seems interested in the new glutin that fixes these issues in the next branch) or people trying to cheat the very clear api in some way (keeping raw dangling pointers to native window around)

@maciejgodek
Copy link
Contributor Author

maciejgodek commented Feb 10, 2021

Huh. That... might work. I'm not (yet) sure it does.

Just to be clear, for that to work the way you describe, the user (e.g. glutin) would have to hang on to their RwLockReadGuard from the time they first started using the NativeWindow for as long as they wish to continue using it. This is where I might be wrong: "using" here is very general and includes any derived objects such as EGLSurface, as well as stuff that's happening asynchronously on the GPU, or in yet another thread if someone insists on that. Compare the docs again.

But in that case the user needs a way of knowing that the NativeWindow is about to go away to perform all requisite cleanup and drop the ReadLockGuard. Currently, on_window_destroyed sends the Destroyed event after obtaining write access to the RwLock and None-ing out the static NativeWindow slot. What's worse, it sends the notification to the winit even loop, which does not seem to notify glutin in any way (at least on respective master branches).

But let me dig around some more, I genuinely might be misunderstanding a thing or two about the whole ecosystem. 😄

@dvc94ch
Copy link
Contributor

dvc94ch commented Feb 10, 2021

goddessfreya the previous glutin maintainer last made contact in feb 2020, never to be heard from again, and taking the glutin improvements with her to the graveyard of dead code.

@maciejgodek
Copy link
Contributor Author

Ok, I'm going to read it all carefully and close my PR for now to reduce confusion.

FWIW I still think there's either a race condition or a potential deadlock in on_window_destroyed. The notification should be sent before obtaining a write lock, so clients have a chance to drop their long-lived read locks, which they should be holding if they have created new objects dependent on NativeWindow.

@MarijnS95
Copy link
Member

MarijnS95 commented Mar 19, 2021

@maciejgodek Did you manage to look into this yet?

I indeed agree that the notification should be sent before grabbing the write lock. Winit should hold on to the read lock as soon as raw_window_handle is called, and drop it on WindowDestroyed after it finished handling that event in user code. Alternatively Winit can grab and cache the lock in WindowCreated and serve from there if raw_window_handle is called. At that point we can only assume user code stops using the window and any implicit dependencies like Vulkan surfaces/swapchains. Reworking Winit to serve the window in ::Resumed and coming up with complicated structures to prevent using it after ::Suspended isn't worth the effort (if properly done for all platforms), nor completely preventing UB at all.

@maciejgodek
Copy link
Contributor Author

maciejgodek commented Mar 19, 2021

I've tried digging into last year's attempted glutin rework but it seems sufficiently different from master that it's mostly a curiosity. :( I'm still not sure how exactly it allows users to keep an EGLContext alive while windows come and go. I'll give it another read some day — I had trouble locating all the dependencies.

As for the more immediate problem, I agree. The reasonable thing is for winit to extend the lifetime of the native window until after the user handles its Suspended event. In that case, android-ndk-rs just needs to make that possible without a race or deadlock, which should require changing approximately two lines of code. :) I will try to put together the two PRs this weekend.

What worries me is whether various winit wrappers (including but not limited to glutin's) are currently capable of intercepting the Suspended event and correctly destroying the implicit dependencies of the NativeWindow without forcing the user to recreate the entire graphics context, which can be quite expensive. But that should probably be discussed elsewhere.

MarijnS95 added a commit to MarijnS95/winit that referenced this issue May 28, 2022
… `Event::Suspended`

This applies rust-mobile/ndk#117
on the `winit` side: Android destroys its window/surface as soon as the
user returns from [`onNativeWindowDestroyed`], and we "fixed" this on
the `ndk-glue` side by sending the `WindowDestroyed` event before
locking the window and removing it: this lock has to wait for any user
of `ndk-glue` - ie. `winit` - to give up its readlock on the window,
which is what we utilize here to give users of `winit` "time" to destroy
any resource created on top of a `RawWindowHandle`.

since we can't pass the user a `RawWindowHandle` through the
`HasRawWindowHandle` trait we have to document this case explicitly and
keep the lock alive on the `winit` side instead.

[`onNativeWindowDestroyed`]: https://developer.android.com/ndk/reference/struct/a-native-activity-callbacks#onnativewindowdestroyed
MarijnS95 added a commit to MarijnS95/winit that referenced this issue Jun 10, 2022
… `Event::Suspended`

This applies rust-mobile/ndk#117
on the `winit` side: Android destroys its window/surface as soon as the
user returns from [`onNativeWindowDestroyed`], and we "fixed" this on
the `ndk-glue` side by sending the `WindowDestroyed` event before
locking the window and removing it: this lock has to wait for any user
of `ndk-glue` - ie. `winit` - to give up its readlock on the window,
which is what we utilize here to give users of `winit` "time" to destroy
any resource created on top of a `RawWindowHandle`.

since we can't pass the user a `RawWindowHandle` through the
`HasRawWindowHandle` trait we have to document this case explicitly and
keep the lock alive on the `winit` side instead.

[`onNativeWindowDestroyed`]: https://developer.android.com/ndk/reference/struct/a-native-activity-callbacks#onnativewindowdestroyed
MarijnS95 added a commit to MarijnS95/winit that referenced this issue Jul 5, 2022
… `Event::Suspended`

This applies rust-mobile/ndk#117
on the `winit` side: Android destroys its window/surface as soon as the
user returns from [`onNativeWindowDestroyed`], and we "fixed" this on
the `ndk-glue` side by sending the `WindowDestroyed` event before
locking the window and removing it: this lock has to wait for any user
of `ndk-glue` - ie. `winit` - to give up its readlock on the window,
which is what we utilize here to give users of `winit` "time" to destroy
any resource created on top of a `RawWindowHandle`.

since we can't pass the user a `RawWindowHandle` through the
`HasRawWindowHandle` trait we have to document this case explicitly and
keep the lock alive on the `winit` side instead.

[`onNativeWindowDestroyed`]: https://developer.android.com/ndk/reference/struct/a-native-activity-callbacks#onnativewindowdestroyed
MarijnS95 added a commit to MarijnS95/winit that referenced this issue Jul 6, 2022
… `Event::Suspended`

This applies rust-mobile/ndk#117
on the `winit` side: Android destroys its window/surface as soon as the
user returns from [`onNativeWindowDestroyed`], and we "fixed" this on
the `ndk-glue` side by sending the `WindowDestroyed` event before
locking the window and removing it: this lock has to wait for any user
of `ndk-glue` - ie. `winit` - to give up its readlock on the window,
which is what we utilize here to give users of `winit` "time" to destroy
any resource created on top of a `RawWindowHandle`.

since we can't pass the user a `RawWindowHandle` through the
`HasRawWindowHandle` trait we have to document this case explicitly and
keep the lock alive on the `winit` side instead.

[`onNativeWindowDestroyed`]: https://developer.android.com/ndk/reference/struct/a-native-activity-callbacks#onnativewindowdestroyed
MarijnS95 added a commit to MarijnS95/winit that referenced this issue Jul 8, 2022
… `Event::Suspended`

This applies rust-mobile/ndk#117
on the `winit` side: Android destroys its window/surface as soon as the
user returns from [`onNativeWindowDestroyed`], and we "fixed" this on
the `ndk-glue` side by sending the `WindowDestroyed` event before
locking the window and removing it: this lock has to wait for any user
of `ndk-glue` - ie. `winit` - to give up its readlock on the window,
which is what we utilize here to give users of `winit` "time" to destroy
any resource created on top of a `RawWindowHandle`.

since we can't pass the user a `RawWindowHandle` through the
`HasRawWindowHandle` trait we have to document this case explicitly and
keep the lock alive on the `winit` side instead.

[`onNativeWindowDestroyed`]: https://developer.android.com/ndk/reference/struct/a-native-activity-callbacks#onnativewindowdestroyed
MarijnS95 added a commit to MarijnS95/winit that referenced this issue Jul 14, 2022
… `Event::Suspended`

This applies rust-mobile/ndk#117
on the `winit` side: Android destroys its window/surface as soon as the
user returns from [`onNativeWindowDestroyed`], and we "fixed" this on
the `ndk-glue` side by sending the `WindowDestroyed` event before
locking the window and removing it: this lock has to wait for any user
of `ndk-glue` - ie. `winit` - to give up its readlock on the window,
which is what we utilize here to give users of `winit` "time" to destroy
any resource created on top of a `RawWindowHandle`.

since we can't pass the user a `RawWindowHandle` through the
`HasRawWindowHandle` trait we have to document this case explicitly and
keep the lock alive on the `winit` side instead.

[`onNativeWindowDestroyed`]: https://developer.android.com/ndk/reference/struct/a-native-activity-callbacks#onnativewindowdestroyed
MarijnS95 added a commit to rust-windowing/winit that referenced this issue Jul 14, 2022
… `Event::Suspended` (#2307)

This applies rust-mobile/ndk#117
on the `winit` side: Android destroys its window/surface as soon as the
user returns from [`onNativeWindowDestroyed`], and we "fixed" this on
the `ndk-glue` side by sending the `WindowDestroyed` event before
locking the window and removing it: this lock has to wait for any user
of `ndk-glue` - ie. `winit` - to give up its readlock on the window,
which is what we utilize here to give users of `winit` "time" to destroy
any resource created on top of a `RawWindowHandle`.

since we can't pass the user a `RawWindowHandle` through the
`HasRawWindowHandle` trait we have to document this case explicitly and
keep the lock alive on the `winit` side instead.

[`onNativeWindowDestroyed`]: https://developer.android.com/ndk/reference/struct/a-native-activity-callbacks#onnativewindowdestroyed
a-llie pushed a commit to a-llie/winit that referenced this issue Aug 24, 2022
Unify `with_app_id` and `with_class` methods

Both APIs are used to set application name. This commit unifies the API
between Wayland and X11, so downstream applications can remove platform
specific code when using `WindowBuilderExtUnix`.

Fixes rust-windowing#1739.

Unify behavior of `resizable` across platforms

This makes X11 and Wayland follow Windows and macOS, so the size of the
window could be set even though it has resizable attribute set to false.

Fixes rust-windowing#2242.

Fix assigning the wrong monitor when receiving Windows move events (rust-windowing#2266)

Fix embedded NULs in C wide strings returned from Windows API (rust-windowing#2264)

On Wayland, fix hiding cursors on GNOME

`wl_pointer::set_cursor` expects a serial number of the last
`wl_pointer::enter` event. However other calls expect latest
observed pointer serial, so this commit tracks both and
use them as required by specification.

Fixes rust-windowing#2273.

Bump windows-sys version to 0.36 (rust-windowing#2277)

Add new `Ime` event for desktop platforms

This commit brings new Ime event to account for preedit state of input
method, also adding `Window::set_ime_allowed` to toggle IME input on
the particular window.

This commit implements API as designed in rust-windowing#1497 for desktop platforms.

On Wayland, provide option for better CSD

While most compositors provide server side decorations, the GNOME
does not, and won't provide them. Also Wayland clients must render
client side decorations.

Winit was already drawing some decorations, however they were bad
looking and provided no text rendering, so the title was missing.
However this commit makes use of the SCTK external frame similar to
GTK's Adwaita theme supporting text rendering and looking similar to
other GTK applications.

Fixes rust-windowing#1967.

Fix warnings on nightly rust (rust-windowing#2295)

This was causing CI to fail: https://github.com/rust-windowing/winit/runs/6506026326

On macOS, emit resize event on `frame_did_change`

When the window switches mode from normal to tabbed one, it doesn't
get resized, however the frame gets resized. This commit makes
winit to track resizes when frame changes instead of window.

Fixes rust-windowing#2191.

Reorganize `EventLoopBuilder::build()` platform documentation

Since there's a "Platform-specific" header, it makes sense to put the
Linux-specific part under it. On the other hand, "Can only be called on
the main thread." is true for all platforms, not just iOS, so there is
no reason to call it out for iOS specifically.

[Windows] Avoid GetModuleHandle(NULL) (rust-windowing#2301)

Use get_instance_handle() over GetModuleHandle(NULL)

On Windows, fix reported cursor position. (rust-windowing#2311)

When clicking and moving the cursor out of the window negative coordinates were not handled correctly.

Revert "On Wayland, fix resize not propagating properly"

This reverts commit 78e5a39.

It was discovered that in some cases mesa will lock the back
buffer, e.g. when making context current, leading to resize
missing. Given that applications can restructure their rendering
to account for that, and that winit isn't limited to playing
nice with mesa reverting the original commit.

Set `WindowBuilder` to must_use

Add X11 opt-in function for device events

Previously on X11, by default all global events were broadcasted to
every winit application. This unnecessarily drains battery due to
excessive CPU usage when moving the mouse.

To resolve this, device events are now ignored by default and users must
manually opt into it using
`EventLoopWindowTarget::set_filter_device_events`.

Fixes (rust-windowing#1634) on Linux.

Prevent null dereference on X11 with bad locale

Remove old dialog fix that is superseded by rust-windowing#2027 (rust-windowing#2292)

This fixes the run_return loop never returning on macos when using multiple windows

Migrate from lazy_static to once_cell

macOS: Emit LoopDestroyed on CMD+Q (rust-windowing#2073)

override applicationWillTerminate:

On Android, use `HasRawWindowHandle` directly from the `ndk` crate (rust-windowing#2318)

The `ndk` crate now implements [`HasRawWindowHandle` directly on
`NativeWindow`], relieving the burden to reimplement it on `winit`.

[`HasRawWindowHandle` directly on `NativeWindow`]: rust-mobile/ndk#274

Run clippy on CI

Fixes rust-windowing#1402.

Make `set_device_event_filter` non-mut

Commit f10a984 added `EventLoopWindowTarget::set_device_event_filter`
with for a mutable reference, however most winit APIs work with
immutable references, so altering API to play nicely with existing APIs.

This also disables device event filtering on debug example.

Make `WindowAttributes` private (rust-windowing#2134)

* Make `WindowAttributes` private, and move its documentation

* Reorder WindowAttributes title and fullscreen to match method order

Build docs on `docs.rs` for iOS and Android as well (rust-windowing#2324)

Remove core-video-sys dependency (rust-windowing#2326)

Hasn't been updated in over 2 years - many open PRs, seems abandoned. Is the cause of several duplicate dependencies in our dependency tree!

Fix macOS 32bit (rust-windowing#2327)

Documentation cleanup (rust-windowing#2328)

* Remove redundant documentation links

* Add note to README about windows not showing up on Wayland

* Fix documentation links

* Small documentation fixes

* Add note about doing stuff after StartCause::Init on macOS

Add `WindowBuilder::transparent`

This is required to help hardware accelerated libraries like glutin
that accept WindowBuilder instead of RawWindowHandle, since the api
to access builder properties directly was removed.

Follow up to 44288f6.

Refine `Window::set_cursor_grab` API

This commit renames `Window::set_cursor_grab` to
`Window::set_cursor_grab_mode`. The new API now accepts enumeration
to control the way cursor grab is performed. The value could be: `lock`,
`confine`, or `none`.

This commit also implements `Window::set_cursor_position` for Wayland,
since it's tied to locked cursor.

Implements API from rust-windowing#1677.

examples/window_run_return: Enable on Android (rust-windowing#2321)

Android also supports `EventLoopExtRunReturn`.  The user will still have
to follow the README to turn this example into a `cdylib` and add the
`ndk_glue::main()` initialization attribute, though.

Fix doubled device events on X11

Fixes rust-windowing#2332

macOS: disallow_highdpi will set explicity the value to avoid the SO value by default (rust-windowing#2339)

ci: Disallow warnings in rustdoc and test private items (rust-windowing#2341)

Make sure `cargo doc` runs cleanly without any warnings in the CI - some
recently introduced but still allowing a PR to get merged.

In case someone wishes to add docs on private items, make sure those
adhere to the same standards.

Bump smithay-client-toolkit to v0.16.0

Disallow multiple EventLoop creation

Fix conflict in `WindowFlags` on Windows

Map XK_Caps_Lock to VirtualKeyCode::Capital (rust-windowing#1864)

This allows applications to handle events for the caps lock key under X11

Less redundancy and improve fullscreen in examples

Remove examples/minimize which is redundant

Implement From<u64> for WindowId and vise-versa

This should help downstream applications to expose WindowId to the end
users via e.g. IPC to control particular windows in multi window
systems.

examples/multiwindow.rs: ignore synthetic key press events

Fix infinite recursion in `WindowId` conversion methods

Add 'WindowEvent::Occluded(bool)'

This commits and an event to track window occlusion state,
which could help optimize rendering downstream.

Add `refresh_rate_millihertz` for `MonitorHandle`

This also alters `VideoMode::refresh_rate` to
`VideoMode::refresh_rate_millihertz` which now returns monitor refresh rate in
mHz.

On Wayland send Focused(false) for new window

On Wayland winit will always get an explicit focused event from the
system and will transfer it downstream. So send focused false to enforce
it.

On Wayland, drop wl_surface on window close

web: Manually emit focused event on mouse click (rust-windowing#2202)

* Manually emit focused event on mouse click

* Update CHANGELOG.md

Co-authored-by: Markus Røyset <maroider@protonmail.com>

web: Add `EventLoop::spawn` (rust-windowing#2208)

* web: Add `EventLoop::spawn`

This is the same as `EventLoop::run`, but doesn't throw an exception in order to return `!`.

I decided to name it `spawn` rather than `run_web` because I think that's more descriptive, but I'm happy to change it to `run_web`.

Resolves rust-windowing#1714

* Update src/platform/web.rs

* Fix outdated names

Co-authored-by: Markus Røyset <maroider@protonmail.com>

Fix changelog entry for `EventLoopExtWebSys` (rust-windowing#2372)

android: Hold `NativeWindow` lock until after notifying the user with `Event::Suspended` (rust-windowing#2307)

This applies rust-mobile/ndk#117
on the `winit` side: Android destroys its window/surface as soon as the
user returns from [`onNativeWindowDestroyed`], and we "fixed" this on
the `ndk-glue` side by sending the `WindowDestroyed` event before
locking the window and removing it: this lock has to wait for any user
of `ndk-glue` - ie. `winit` - to give up its readlock on the window,
which is what we utilize here to give users of `winit` "time" to destroy
any resource created on top of a `RawWindowHandle`.

since we can't pass the user a `RawWindowHandle` through the
`HasRawWindowHandle` trait we have to document this case explicitly and
keep the lock alive on the `winit` side instead.

[`onNativeWindowDestroyed`]: https://developer.android.com/ndk/reference/struct/a-native-activity-callbacks#onnativewindowdestroyed

web: add `with_prevent_default`, `with_focusable` (rust-windowing#2365)

* web: add `with_prevent_default`, `with_focusable`

`with_prevent_default` controls whether `event.preventDefault` is called

`with_focusable` controls whether `tabindex` is added

Fixes rust-windowing#1768

* Remove extra space from CHANGELOG

windows: Use correct value for mouse wheel delta (rust-windowing#2374)

Make winit focus take activity into account on Windows (rust-windowing#2159)

winit's notion of "focus" is very simple; you're either focused or not.
However, Windows has both notions of focused window and active window
and paying attention only to WM_SETFOCUS/WM_KILLFOCUS can cause a window
to believe the user is interacting with it when they're not. (this
manifests when a user switches to another application between when a
winit application starts and it creates its first window)

Fix typos (rust-windowing#2375)

Bump sctk-adwaita to 0.4.1

This should force the use of system libraries for Fontconfig
and freetype instead of building them with cmake if missing.

This also fixes compilation failures on nightly.

Fixes rust-windowing#2373.

Tidy up "platform-specifc" doc sections (rust-windowing#2356)

* Tidy up "platform-specific" doc sections

* Unrelated grammatical fix

* Subjective improvements

Android: avoid deadlocks while handling UserEvent (rust-windowing#2343)

Replace `Arc<Mutex<VecDeque<T>>` by `mpsc`

Update raw-window-handle to v0.5.0

This updates raw-window-handle to v0.5.0.

On macOS, fix confirmed character inserted

When confirming input in e.g. Korean IME or using characters like
`+` winit was sending those twice, once via `Ime::Commit` and the
other one via `ReceivedCharacter`, since those events weren't generating
any `Ime::Preedit` and were forwarded due to `do_command_by_selector`.

Add method to hook xlib error handler

This should help glutin to handle errors coming from GLX
and offer multithreading support in a safe way.

Fixes rust-windowing#2378.

Windows: apply skip taskbar state when taskbar is restarted (rust-windowing#2380)

Fix hiding a maximized window On Windows (rust-windowing#2336)

Bump `ndk` and `ndk-glue` dependencies to stable `0.7.0` release (rust-windowing#2392)

Fix type hint reference for xlib hook

Consistently deliver a Resumed event on all platforms

To be more consistent with mobile platforms this updates the Windows,
macOS, Wayland, X11 and Web backends to all emit a Resumed event
immediately after the initial `NewEvents(StartCause::Init)` event.

The documentation for Suspended and Resumed has also been updated
to provide general recommendations for how to handle Suspended and
Resumed events in portable applications as well as providing
Android and iOS specific details.

This consistency makes it possible to write applications that lazily
initialize their graphics state when the application resumes without
any platform-specific knowledge. Previously, applications that wanted
to run on Android and other systems would have to maintain two,
mutually-exclusive, initialization paths.

Note: This patch does nothing to guarantee that Suspended events will
be delivered. It's still reasonable to say that most OSs without a
formal lifecycle for applications will simply never "suspend" your
application. There are currently no known portability issues caused
by not delivering `Suspended` events consistently and technically
it's not possible to guarantee the delivery of `Suspended` events if
the OS doesn't define an application lifecycle. (app can always be
terminated without any kind of clean up notification on most
non-mobile OSs)

Fixes rust-windowing#2185.

ci: manually point ANDROID_NDK_ROOT to latest supplied version

It seems the symlink to `ndk-bundle` and this environment variable
pointing to it have been removed to prevent the sdkmanager from failing,
when finding the SDK setup to be in an "indeterminate" state.  It is now
up to the users themselves to install an NDK through that tool or point
the right variables to a preinstalled "latest" NDK.

actions/runner-images#2689
actions/runner-images#5926

Fix changelog entry wrt scrolling

The breaking change was put into the wrong release section.

Release 0.27.0 version

Explicitly specify minimum supported rust version

This should help with distributing apps using winit.

Fixes rust-windowing#1075.

On X11, fix crash when can't disable IME

Fixes rust-windowing#2402.

Release 0.27.1 version

Windows: respect min/max sizes when creating the window (rust-windowing#2393)

On X11, fix window hints not persisting

This commit fixes the issue with min, max, and resize increments
not persisting across the dpi changes.

Fix tracking of phase changes for mousewheel on trackpad (rust-windowing#2158)

On Windows, add opt-in function for device events (rust-windowing#2409)

Add CODEOWNERS file (rust-windowing#2420)

* Add CODEOWNERS file

This makes it very clear when you're stepping down from the post as a maintainer, and makes it clear for users who is expected to review their PR

* Fix grammar

* Make @kchibisov receive pings for the X11 platform

* Fix typo

Implement version 0.4 of the HasRawWindowHandle trait

This makes Winit 0.27 compatible with crates like Wgpu 0.13 that are
using the raw_window_handle v0.4 crate and aren't able to upgrade to 0.5
until they do a new release (since it requires a semver change).

The change is intended to be self-contained (instead of pushing
the details into all the platform_impl backends) since this is only
intended to be a temporary trait implementation for backwards
compatibility that will likely be removed before the next Winit release.

Fixes rust-windowing#2415.

Fix missleading breaking change on Windows

The applications should not rely on not-implemented behavior and
should use the right functions for that.

Remove redundant steps from CI

Tests are already building the entire crate, so no need for a
separate builds slowing down the CI.

On Wayland, fix `Window::request_redraw` being delayed

On Waylnad when asking for redraw before `MainEventsCleared`
would result for redraw being send on the next event loop tick,
which is not expectable given that it must be delivered on the same
event loop tick.

Release 0.27.2 version

On Windows, improve support for undecorated windows (rust-windowing#2419)

Add touchpad magnify and rotate gestures support for macOS (rust-windowing#2157)

* Add touchpad magnify support for macOS

* Add touchpad rotate support for macOS

* Add macOS rotate and magnify gesture cancelled phases

* Correct docs for TouchpadRotate event

* Fix tracing macros

Document `WindowEvent::Moved` as unsupported on Wayland

Update `sctk-adwaita` to use `ab_glyph`

The crossfont will still be available under the option.

Mark new events as breaking change

Adding a new enum variant is a breaking change in winit.

Co-Authored-By: kas <exactly-one-kas@users.noreply.github.com>
Co-Authored-By: Artur Kovacs <kovacs.artur.barnabas@gmail.com>
Co-Authored-By: Markus Siglreithmaier <m.siglreith@gmail.com>
Co-Authored-By: Murarth <murarth@gmail.com>
Co-Authored-By: Yusuke Kominami <yukke.konan@gmail.com>
Co-Authored-By: moko256 <koutaro.mo@gmail.com>
Co-Authored-By: Mads Marquart <mads@marquart.dk>
Co-Authored-By: Markus Røyset <maroider@protonmail.com>
Co-Authored-By: Marijn Suijten <marijns95@gmail.com>
Co-Authored-By: Kirill Chibisov <contact@kchibisov.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants