bevy_window: Split RawHandleWrapper out into Display wrapper#20357
Draft
MarijnS95 wants to merge 1 commit intobevyengine:mainfrom
Draft
bevy_window: Split RawHandleWrapper out into Display wrapper#20357MarijnS95 wants to merge 1 commit intobevyengine:mainfrom
RawHandleWrapper out into Display wrapper#20357MarijnS95 wants to merge 1 commit intobevyengine:mainfrom
Conversation
Contributor
|
Welcome, new contributor! Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨ |
alice-i-cecile
added
A-Windowing
MarijnS95
force-pushed
the
raw-display-handle
branch
from
88099c6 to
61045bd
Compare
alice-i-cecile
added
D-Complex
Long ago `raw-window-handle` and `winit` split out a `RawDisplayHandle` type and respective traits for dealing with the connection - or at the very least type - of a compositor, and typically implement this for a `Window` directly. `wgpu` and `bevy` seem to have caught on to the latter and folded the two traits/types together because `Window` provides it, but miss a critical goal here: that `(Raw)DisplayHandle` is important for initialization of certain graphics APIs. In the case of Wayland all resources are unique per connection, and in general for others it's important to distinguish between Wayland and X11 if `winit` chose one over the other, even if both are available; currently that's just guesswork inside `wgpu`. Newer APIs like Vulkan don't suffer from this, but older graphics APIs like OpenGL and specifically the EGL backend (or GLX for X11) set up their entire state based on the compositor connection (alternatives are available) even if it's ultimately "only" important for the surface that is going to be rendered into. Note that I haven't yet checked all the safety constraints carefully in this PR; some existing messages seem flawed but I need to perform a clean audit from scratch to denote what limitations should apply to the newly proposed `RawDisplayHandleWrapper` as well.
MarijnS95
force-pushed
the
raw-display-handle
branch
from
61045bd to
4064f7b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Objective
BadDisplayafter winit 0.30 on Wayland OpenGL #13923 and Crash due to wgpu during startup on Wayland #14494 by getting rid of some duplication.Solution
Long ago
raw-window-handleandwinitsplit out aRawDisplayHandletype and respective traits for dealing with the connection - or at the very least type - of a compositor, and typically implement this for aWindowdirectly.wgpuandbevyseem to have caught on to the latter and folded the two traits/types together becauseWindowprovides it, but miss a critical goal here: that(Raw)DisplayHandleis important for initialization of certain graphics APIs. In the case of Wayland all resources are unique per connection, and in general for others it's important to distinguish between Wayland and X11 ifwinitchose one over the other, even if both are available; currently that's just guesswork insidewgpu.Newer APIs like Vulkan don't suffer from this, but older graphics APIs like OpenGL and specifically the EGL backend (or GLX for X11) set up their entire state based on the compositor connection (alternatives are available) even if it's ultimately "only" important for the surface that is going to be rendered into.
Note that I haven't yet checked all the safety constraints carefully in this PR; some existing messages seem flawed but I need to perform a clean audit from scratch to denote what limitations should apply to the newly proposed
RawDisplayHandleWrapperas well.Testing
cargo r --example 3d_bloom -Fwaylandon a Wayland compositor.