Skip to content

Conversation

@richerfu
Copy link

@richerfu richerfu commented Feb 20, 2025

This is the first draft PR to support openharmony for softbuffer. There are two things need to do:

  1. OS don't tigger Resumed event and softbuffer example will crash( Maybe fix it in 2025.06 ).
  2. We need to run some examples to make sure adaption works.

@madsmtm
Copy link
Member

madsmtm commented Feb 20, 2025

Thanks for the draft PR, is it useful to see how OpenHarmony is used!

CC rust-windowing/winit#4081, we shouldn't merge this before the Winit side is resolved.

@richerfu
Copy link
Author

I'm planning to use it with iced see related issue with iced-rs/iced#302

Copy link
Member

@madsmtm madsmtm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the response in rust-windowing/winit#4081 (comment), I'd be fine with merging this before Winit support.

@richerfu richerfu force-pushed the master branch 4 times, most recently from 48ca611 to 8b2dc97 Compare March 18, 2025 02:18
@richerfu richerfu marked this pull request as ready for review March 18, 2025 02:33
@richerfu
Copy link
Author

richerfu commented Mar 18, 2025

I made an example to test softbuffer in OpenHarmony and seems like render successfully. I think it's time to review my code. Waiting for your fallback, thanks @madsmtm

Comment on lines +14 to +15
// Install the Android event loop extension if necessary.
builder.with_openharmony_app(app);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Android? 👀

Comment on lines +153 to +157
// Swizzle colors from RGBX to BGR
let [b, g, r, _] = pixel.to_le_bytes();
output[i * 4].write(b);
output[i * 4 + 1].write(g);
output[i * 4 + 2].write(r);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this entire module was copied from Android, keep in mind that I recently fixed some typos in this borked swizzle: ae1565b

Comment on lines +24 to +27


# OpenHarmony
/src/ohos.rs @richerfu
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One newline please, and an empty one at the end to satisfy GitHub:

Suggested change
# OpenHarmony
/src/ohos.rs @richerfu
# OpenHarmony
/src/ohos.rs @richerfu

}

#[cfg(not(any(target_arch = "wasm32", target_arch = "wasm64")))]
#[cfg(not(any(target_arch = "wasm32", target_arch = "wasm64", target_env = "ohos")))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be in the cfg above as well; but there's no exception for Android so OHOS likely doesn't need one either?


[target.'cfg(all(unix, not(any(target_vendor = "apple", target_os = "android", target_os = "redox"))))'.dependencies]
[target.'cfg(target_env = "ohos")'.dependencies]
ohos-native-window-binding = { version = "0.1" }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
ohos-native-window-binding = { version = "0.1" }
ohos-native-window-binding = "0.1"

Same below perhaps?

winit::platform::web::EventLoopExtWebSys::spawn_app(event_loop, app);

#[cfg(target_env = "ohos")]
winit::platform::ohos::EventLoopExtOpenHarmony::spawn_app(event_loop, app);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know why OHOS doesn't support run_app()? Maybe I need to investigate the same for Android which also isn't required to run a blocking loop (that's pretty bad for the ANativeActivity_onCreate() entrypoint too, which is why wrapper crates like android-activity execute the users' entrypoint in a new thread).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants