Skip to content
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

Closed
notgull opened this issue Jul 10, 2022 · 3 comments
Closed

Add a type for a more generic window #94

notgull opened this issue Jul 10, 2022 · 3 comments

Comments

@notgull
Copy link
Member

notgull commented Jul 10, 2022

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 return RawWindowHandle for use in e.g. wgpu.

However, I would be unable to return a RawWindowHandle from my GUI instance if it is using breadx. I could adapt this by returning an Option<RawWindowHandle> instead of a RawWindowHandle. However, this would mean that I couldn't implement HasRawWindowHandle for this system, unless I want the implementation for that to panic when breadx is used.

I was thinking that this crate could add a more generic window handle, like this:

struct GenericHandle {
    display: Box<dyn Any>,
    window: usize,
}

Although I imagine there's a better way of doing this.

@kchibisov
Copy link
Member

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.

@notgull
Copy link
Member Author

notgull commented Jul 10, 2022

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.

@notgull
Copy link
Member Author

notgull commented Mar 17, 2023

I'm no longer doing this. This would probably be solved by #104 or, more realistically, making the traits return Result.

@notgull notgull closed this as not planned Won't fix, can't repro, duplicate, stale Mar 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants