You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 3, 2025. It is now read-only.
Hi, I am not sure if this would make sense to go in this crate, but I am interested in a case where I need an eventually consistent WebGPU Texture which is not Clone, Eq, or PartialEq. It is not important to me if the same exact texture is explicitly written twice and then read twice. Rather, I simply want to ensure that I am not displaying old frames, only the latest frame, in the case that frames are produced faster than the VSync rate.
Given this, would it make sense to add a variant of the Eventual that always wraps the contained item in an Arc and then uses pointer equality (via https://doc.rust-lang.org/std/sync/struct.Arc.html#method.ptr_eq) to satisfy the Eq requirement. This would still have eventual consistency all the same, but it might trigger someone downstream to get the same value twice. For many applications this is acceptable and possibly even required if the resources are too large or time consuming to compare (like GPU memory). In my case I will probably work around this issue by creating a newtype that implements Eq and PartialEq explicitly using Arc::ptr_eq, but I think having something like this in this crate would be useful for others who have a similar problem.
Hi, I am not sure if this would make sense to go in this crate, but I am interested in a case where I need an eventually consistent WebGPU Texture which is not
Clone,Eq, orPartialEq. It is not important to me if the same exact texture is explicitly written twice and then read twice. Rather, I simply want to ensure that I am not displaying old frames, only the latest frame, in the case that frames are produced faster than the VSync rate.Given this, would it make sense to add a variant of the
Eventualthat always wraps the contained item in anArcand then uses pointer equality (via https://doc.rust-lang.org/std/sync/struct.Arc.html#method.ptr_eq) to satisfy theEqrequirement. This would still have eventual consistency all the same, but it might trigger someone downstream to get the same value twice. For many applications this is acceptable and possibly even required if the resources are too large or time consuming to compare (like GPU memory). In my case I will probably work around this issue by creating a newtype that implementsEqandPartialEqexplicitly usingArc::ptr_eq, but I think having something like this in this crate would be useful for others who have a similar problem.Thoughts?