use wgpu4k and add Android basic rendering

[ygdrasil-io]

Not yet compiling. Still plenty of work ahead!

I'm keeping this as a draft until the full release on Maven Central. (For now, I'm using snapshot repositories for faster iteration.)

I'm using this pull request to improve the binding by adding missing features. Functions that deviate significantly from the original specifications are implemented as extensions.

I plan to switch enumeration names to CamelCase to align with Kotlin conventions and distinguish them from C/Java styles.

After replacing the original implementation, I'll create the basic setup to get Android working.

While a review isn't necessary at this stage, I'm open to any feedback you may have.

[LeHaine]

This is great! You are a workhorse. Looking good so far but I can get a deeper dive into this when I am back at some point next week.

Nicd work.

[ygdrasil-io]

This is now compiling, but some examples are crashing, and I'm unsure if the colors are always matching the initial results. While promising, there's still work to be done!

[ygdrasil-io]

I'm making good progress on a generator to easily update the bindings with each native library upgrade. At the current pace, it should be finished within one or two weeks.

I'll leverage the upcoming iteration in gfx-rs/wgpu-native#427 to test the generator and then update this PR with any necessary bug fixes.

I hope the generator will help stabilize support for all platforms and facilitate publishing the entire project on Maven Central.

@LeHaine In the meantime, if you have time, please review the changes and let me know if you find any issues. Based on the current work, only some (potentially many) typos in the binding will be corrected to align more closely with the specification. However, the overall usage should remain consistent.

[LeHaine]

Great news and great work! I will check it out today.

[LeHaine]

@ygdrasil-io I've pulled down your code and have been testing. Overall, working pretty well! But I have run into a couple issues:

1, When the SurfaceTexture is lost (e.g. from resizing the window), we usually close / release the surface texture. It seems that the underlying texture can be invalid / null. In the WGPU native examples, they do show that they check if the texture is not null before attempting to release it.

SurfaceTextureStatus.lost -> {
-   surfaceTexture.texture.close() // this is the cause
+  surfaceTexture.texture?.close() // might need to make the underlying texture nullable
    graphics.configureSurface(
        setOf(TextureUsage.renderAttachment),
        preferredFormat,
        PresentMode.fifo,
        graphics.surface.supportedAlphaMode.first()
    )
    logger.info { "getCurrentTexture status=$status" }
    return@onUpdate
}

2. A strange one that I am seeing is a device's SupportedLimits not returning the expected value. The error: Dynamic binding index 0 (targeting bind group 0, binding 0) with value 64, does not respect device's requested 'min_uniform_buffer_offset_alignment' limit: 256 when using the value from:

device.limits.minUniformBufferOffsetAlignment

This returns a value of 64 but for some reason is expecting a value of 256 which causes a validation error and crashes.

From a quick glance, it looks like the underlying Device is using the Adapter limits instead of the Device:

val supportedLimits = WGPUSupportedLimits.allocate(arena)
wgpu_h.wgpuAdapterGetLimits(handler, supportedLimits) // <---- this guy
map(WGPUSupportedLimits.limits(supportedLimits))