Various fixes against the v25 branch.

[oliverbestmann]

I can split the PR up into multiple small onces, but as the v25 PR is already one single big PR, i just went with another big one ;)

• Update to go 24 in go.mod file
• Go against wgpu 27 (current version)
• Adjust js api to match the non-js api in multiple places
• Fix runtime/cgo: misuse of an invalid Handle #6 by not using pointers to cgo.Handle
• Expose wgpu DesiredMaximumFrameLatency in SurfaceConfiguration
• Use an optimized implementation for Queue.WriteBuffer and Queue.WriteTexture
• Handle missing VertexFormat in VertexFormat.Size()
• Implement missing methods on Texture for js.

[oliverbestmann]

Fixed the handle issue by introducing our own handle type that can be legally converted into an unsafe.Pointer.

[oliverbestmann]

Note: i've now forked the repository and added more things on the main branch, that you might not want to have upstream. This includes improved garbage collection of wgpu resources, makeing calls to Release unecessary, as well as removing goal and moving the prebuild libraries into branches, as wgpu v27 is above the go get limit of 512mb.

[mreinstein]

It would be really nice to hear from the maintainers, if there are plans to either merge these improvements or cherry pick certain things out of it.

[rcoreilly]

@kkoreilly and I will have a chance to discuss this soon and will post an update within a couple of weeks hopefully!

[kkoreilly]

@oliverbestmann Thanks for these changes! Apologies for the very delayed response, I've been quite busy.

Overall things look good, I just have a couple comments below.

[kkoreilly]

I'm curious why this change is necessary as opposed to the previous jsx.BytesToJS approach. Does this solve the occasional crashing that occurred previously, or is there another motivation?

[oliverbestmann]

Performance iirc. It was precisely jumping to is and back a billion of times. Also yes, it crashed here previously, that got better now. One more thing: As you only take the uintptr of the Adress, the gc can theoretically dealloc the slice before it is used at the end of the function.

[kkoreilly]

Why is core now an indirect dependency?

[oliverbestmann]

I thought I got rid of that too. I would need to check for what that is used ;)

[kkoreilly]

@oliverbestmann The changes on your main branch look good overall, and if you are interested in filing separate PRs for them, that would be awesome (no worries if not).

For the binary size limit, I wonder whether it might be easier to use different modules within the same branch rather than in separate branches? You could have separate go.mod files in each lib/android etc directory, right?

Could you briefly explain how you implemented the garbage collection and whether there are any major negative side effects of that?

Thanks for all of your contributions, and apologies again for our unresponsiveness, I've been very busy but should hopefully have more time to respond going forward.

[oliverbestmann]

Regarding the binary size limit: I am not sure if I tried that. I think the size limit is per shallow clone of the repository, not the module subdirectory.

Garbage collection: it is really just registering finalizers like here: https://github.com/oliverbestmann/webgpu/blob/main/wgpu/wgpu.go#L122 Special care needs to be taken when addRef is used, see a few lines above. The release method was made idempotent, so it can be called multiple times without crashing: https://github.com/oliverbestmann/webgpu/blob/main/wgpu/gen_types.go#L266
I did not experience any negative sideeffects.

I am currently also very busy due to $work and family, so I probably won't create multiple pull requests. I am sorry!

[rcoreilly]

One consideration for timing of update of underlying libraries, assuming there remains some kind of cost to updating the libraries more frequently (hopefully @kkoreilly 's proposed solution might avoid that??) is the possible resolution of this issue: gfx-rs/wgpu#8119 -- this would probably be the single biggest issue fix for my usage.