-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a type for a more generic window #94
Comments
Unfortunatelly you won't be able to achieve so with e.g. wgpu. The main issue with custom rust based raw window handles is that you don't have an ability to initialize backend surface out of them. The only thing you can use your custom backend for is software rendering with your own implementation of everything related. To make your generic handler being actually useful for something like wgpu, you'd need to commit add implementation for your particular surface handler into mesa. Which I doubt you will. In general I don't see much use for those, since those are not applicable to underlying system API. And if the platform would go into mesa it must have a C ABI iirc, so you'll be able to express your custom handler with pointers. In general, I understand that the need for something like that might be required, but in reality I'm not sure there's any value out of them or you can do anything with them. |
I'm aware. Even if the end result is "it doesn't do anything useful", I'd still like the ability to return something for esoteric platforms. Now that I think about it, perhaps a ZST type would be more appropriate for this use case. |
I'm no longer doing this. This would probably be solved by #104 or, more realistically, making the traits return |
I'm writing a GUI framework that may use
breadx
, which is an X implementation not based on either Xlib or XCB, but written by hand. I'd like this GUI framework to be able to returnRawWindowHandle
for use in e.g.wgpu
.However, I would be unable to return a
RawWindowHandle
from my GUI instance if it is usingbreadx
. I could adapt this by returning anOption<RawWindowHandle>
instead of aRawWindowHandle
. However, this would mean that I couldn't implementHasRawWindowHandle
for this system, unless I want the implementation for that to panic whenbreadx
is used.I was thinking that this crate could add a more generic window handle, like this:
Although I imagine there's a better way of doing this.
The text was updated successfully, but these errors were encountered: