Conversation
|
Thanks :) In principle I'd also like to upgrade to '29, but I'd rather not at 1900 new lines of code and support three wgpu versions at the same time. The main dependency with wgpu we've got in our repo at the moment is bevy, which needs -27 for the 0.18 release and the bevy gpu example that uses bevy from git, which uses -28. I also see vello as a future dependency to Slint that in turn depends on wgpu. I'd like to not support more than two wgpu versions at the same time. Now that bevyengine/bevy#23544 landed, the only path that I can see is either
With (1) we end up supporting -28 and -29 (or we could go with -29 only). With (2) we end up supporting -27 and -29. Not great, but not bad. My feeling is to wait a little, but if there's sufficient demand then I'd prefer to go (2) instread of supporting -27, -28, and -29 at the same time. |
|
I just updated because I required for my project and so someone else can add the support faster with prior work :) |
|
I'm just leaving it here since I'm also waiting for the upgrade to 29. |
Two new library consumers of reco-core, both with FRICTION.md documenting API pain points encountered while building them: reco-gui: Slint-based preview GUI (Material dark theme). Currently uses CPU readback bridge (2-5ms/frame at 1080p) because Slint 1.15 binds wgpu 27/28 and reco-core uses wgpu 29. Zero-copy path blocked on slint-ui/slint#11378. reco-obs: OBS Studio source plugin as cdylib. Double-buffered NV12 readback pipes stitched frames into OBS via its async video source callback. Shares the same readback-boilerplate pain as reco-gui. The FRICTION.md files flag API gaps (no RGBA readback helper, render_to_target/render_to_view asymmetry, YuvPlanes stride mismatch, EOF ambiguity in FrameSource) that will drive reco-core API improvements in follow-up work.
3 participants
No description provided.