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
Supporting multiple version would be nice of course but currently I can't estimate the overhead for this as I haven't been following the rwh api changes lately tbh
Supporting multiple versions on the producer end is really easy via just implementing the traits for each version of the crate (feature-gated so that you don't have to have duplicate raw-window-handle dependencies). However, doing this for the consumer end (here and in ash-window for example) is more problematic as we should essentially have multiple versioned functions of metal_layer_from_handle() for each version of raw-window-handle, Alternatively we could implement a conversion trait for every version of raw-window-handle.
@notgull suggestions (preferably in a separate issue/PR/discussion)?
From this crate's API, it looks like "multiple versioned functions of metal_layer_from_handle() for each version of raw-window-handle" is probably the only good option.
So we'd end up with metal_layer_from_raw_window_handle_05() etc. Probably the same for ash-window even though unfortunately that match block is much bigger?
Supporting multiple versions on the producer end is really easy via just implementing the traits for each version of the crate (feature-gated so that you don't have to have duplicate
raw-window-handle
dependencies). However, doing this for the consumer end (here and inash-window
for example) is more problematic as we should essentially have multiple versioned functions ofmetal_layer_from_handle()
for each version ofraw-window-handle
, Alternatively we could implement a conversiontrait
for every version ofraw-window-handle
.@notgull suggestions (preferably in a separate issue/PR/discussion)?
Originally posted by @MarijnS95 in #10 (comment)
The text was updated successfully, but these errors were encountered: