jazzfool

I found a small bug which should improve performance slightly. However, regarding the performance overall, I did find the source of the issue as to why performance ends up being...

That's right. If WGPU implements the native video decoding extensions for each API then that would result in almost no overhead since the memory doesn't need to move anywhere. The...

Referring to the external memory extensions, actually gstreamer does expose `glimagesink`, `vulkansink`, and `d3d11videosink`. Of course in the interest of supporting interop with all WGPU backends you'd want to pick...

I have implemented hardware accelerated NV12 to RGB conversion that does not rely on the WGPU feature gate in 9d60f26. With that, CPU usage has been reduced by around 30-40%....

I did find a leak relating to GPU textures/buffers and have fixed it on master (cd978e3) - whether this accounts for as much as 100MB of stale memory however really...

With b4fceaf, your implementation of `from_pipeline` should now work. I would like to bring back `Video::from_pipeline` but there's really no good way to do it. It's not as simple as...

Regarding the first point, what exactly did you change in the gstreamer pipeline that saw the improvement? I'm open to adding a `Video::from_pipeline` constructor but at the same time I'd...

Ah, yeah that's a fairly bespoke pipeline. It makes sense to support custom pipelines for things like `v4l2src`, but yes we would just need to ensure `name=app_sink` exists etc. Also...

Resolved by #10

This is caused by [the `VertexBuilder` given to Lyon](https://github.com/ggez/ggez/blob/74ed4c7688cdd03a84c5c98f9c8650ec3947cf07/src/graphics/mesh.rs#L689). Interestingly, this has been an issue [for a long time](https://github.com/ggez/ggez/blob/af7bf183d07235b8cd589065993657a813f72d8b/src/graphics/mesh.rs#L499) (pre-WGPU), but it wasn't noticed then because textured meshes could only...