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
This library does some pretty sketchy things internally (abuse of the Deref and DerefMut traits plus some weird, but sound, uses of std::mem::transmute() to simulate inheritance, etc), and its user ergonomics aren't the best either. I've learned quite a lot since I first started this project, and I would like to completely redo this library to make better use of the type system and be more user-friendly.
For one, it is possible to fully reimplement this style of API using 100% safe and idiomatic code (Playground link), while also fixing #93. Other aspects of this library could use a lick of paint; for example, the CaptureOptions interface of the raw RenderDoc API could be abstracted over with a type safe interface, and the frame capture methods could be made more idiomatic too (consider providing a Drop guard for starting and ending a frame capture, for instance).
Finally, the RenderDoc<V> struct could offer a default generic type parameter which defaults to the newest supported API version to make things easier for users who don't really care about selecting a specific API version themselves.
The whole type-safe runtime downgrading API with .into() is honestly an unnecessary gimmick and should be removed. But perhaps offering a fallible API for users to upgrade their RenderDoc<V> instance to a newer version, if they so choose, would be more useful (one would select a minimum supported version first, and if so desired, test at runtime whether RenderDoc handed over a newer version and then switch to that).
The text was updated successfully, but these errors were encountered:
This library does some pretty sketchy things internally (abuse of the
Deref
andDerefMut
traits plus some weird, but sound, uses ofstd::mem::transmute()
to simulate inheritance, etc), and its user ergonomics aren't the best either. I've learned quite a lot since I first started this project, and I would like to completely redo this library to make better use of the type system and be more user-friendly.For one, it is possible to fully reimplement this style of API using 100% safe and idiomatic code (Playground link), while also fixing #93. Other aspects of this library could use a lick of paint; for example, the
CaptureOptions
interface of the raw RenderDoc API could be abstracted over with a type safe interface, and the frame capture methods could be made more idiomatic too (consider providing aDrop
guard for starting and ending a frame capture, for instance).Finally, the
RenderDoc<V>
struct could offer a default generic type parameter which defaults to the newest supported API version to make things easier for users who don't really care about selecting a specific API version themselves.The whole type-safe runtime downgrading API with
.into()
is honestly an unnecessary gimmick and should be removed. But perhaps offering a fallible API for users to upgrade theirRenderDoc<V>
instance to a newer version, if they so choose, would be more useful (one would select a minimum supported version first, and if so desired, test at runtime whether RenderDoc handed over a newer version and then switch to that).The text was updated successfully, but these errors were encountered: