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

Make display, surface and context creation safe #1582

Closed
wants to merge 1 commit into from

Conversation

notgull
Copy link
Member

@notgull notgull commented Mar 24, 2023

  • Tested on all platforms changed
  • Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
  • Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
  • Created or updated an example program if it would help users understand this functionality

Uses rust-windowing/raw-window-handle#116 to make display, surface and context creation safe.

I want to get a good idea of what this kind of API would look like. I want to test out the new safe window handles before they're released onto the world.

@notgull notgull mentioned this pull request Mar 26, 2023
4 tasks
@notgull
Copy link
Member Author

notgull commented Mar 26, 2023

Hmm, looks like this model kind of breaks glutin-winit. Right now, an &EventLoopWindowTarget is used to provide the display handle for creating the Display. However, since the reference to the ELWT will disappear for event handling, this can't be used as a persistent handle for the display.

A solution would be to use an &Window or an Rc<Window> instead, but the Display initialization generally happens before the Window is created. Maybe we could add a type to winit similar to EventLoopWindowTarget that doesn't disappear during event handling?

@notgull
Copy link
Member Author

notgull commented Jul 15, 2023

Rebased around rust-windowing/raw-window-handle#125, aka raw-window-handle v0.6

@notgull
Copy link
Member Author

notgull commented Dec 17, 2023

Rebased on the newest master

@notgull
Copy link
Member Author

notgull commented Dec 17, 2023

The main caveat is that the OwnedDisplayHandle change wasn't accepted into winit, so the DisplayBuilder function is now unsafe.

Support for GLX

Partial EGL support

Finish out full glutin implementation

Port over aux. crates

Fix doctests

Fix eminent compile errors

Signed-off-by: John Nunley <[email protected]>

Update CHANGELOG.md

Signed-off-by: John Nunley <[email protected]>

Add accessors for display and window

Signed-off-by: John Nunley <[email protected]>
@emilk
Copy link

emilk commented Jan 17, 2024

Any chance for a glutin release with raw-window-handle 0.6? 🙏

@kchibisov
Copy link
Member

I'm not sure how soon, since I don't have time to review the glutin stuff now. it's not like you can't use it at all if you have only raw-window-handle 0.6, since you can convert 0.6 to 0.5 and e.g. winit provides all 3 of them at the same time, so you can pick 0.5 for glutin and 0.6 for other winit stuff.

But it'll be review/merge within a month...

@emilk
Copy link

emilk commented Jan 17, 2024

Ah, winit supports all three of them at the same time, I didn't realize that (thought I had to pick one). Then I can probably figure something out. Thanks for the pointer!

EDIT: actually, juggling several rwh-versions is a nightmare.
EDIT2: ok, I think I have figured it out :)

@MarijnS95
Copy link
Member

@emilk what makes you juggle multiple versions, instead of locking winit to 0.5 and using that in glutin?

@emilk
Copy link

emilk commented Jan 18, 2024

eframe has to support both glutin (locked at 0.5) and wgpu (locked at 0.6).

@MarijnS95
Copy link
Member

Right, that is indeed a painful situation.

@kchibisov kchibisov mentioned this pull request Mar 18, 2024
4 tasks
@notgull
Copy link
Member Author

notgull commented Mar 18, 2024

Don't really feel like rebasing this and it's unlikely to be reviewed, so I'll abandon this in favor of #1670

@notgull notgull closed this Mar 18, 2024
@kchibisov
Copy link
Member

It'll be though, but there's a big chance that I write parts myself. Like I'd like to use safe handles myself, it's just winit is lacking and I said it to you before. Forcing everyone to just start Arc everything sounds a bit wasteful.

@notgull notgull deleted the safe-window-handle branch March 19, 2024 02:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants