Skip to content

Conversation

@atlv24
Copy link
Contributor

@atlv24 atlv24 commented Dec 13, 2025

Objective

  • Selecting an unsupported PresentMode crashes. Lets not do that.

Solution

  • Filter by capabilities and assume reasonable fallbacks.

Testing

Copy link
Member

@tychedelia tychedelia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this is reallly helpful to prevent an unnecessary crash.

Copy link
Member

@janhohenheim janhohenheim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MInor nit, nothing blocking :)

);
});
if new_present_mode != present_mode && fallbacks.contains(&present_mode) {
info!("PresentMode {present_mode:?} requested but not available. Falling back to {new_present_mode:?}");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be a little chatty for something like AutoNoVsync where it's not really like you "requested" Immediate, you're more like "just gimme whatever works"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AutoNoVsync and AutoVsync will not log because of the fallbacks.contains(&present_mode) check

};
let fallbacks = match present_mode {
wgpu::PresentMode::AutoVsync => {
&[wgpu::PresentMode::FifoRelaxed, wgpu::PresentMode::Fifo][..]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does the &[][..] syntax do?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It turns it into a slice. Rust thinks these are array references if we dont do that, and the match complains about heterogeneous return value.

wgpu::PresentMode::Fifo,
][..],
wgpu::PresentMode::Mailbox => &[
wgpu::PresentMode::Mailbox,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it intentional that in some cases the fallbacks start with the mode they're for, and in other cases not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, AutoVsync and AutoNoVsync are not actual presentation modes, they never show up in surface caps. Wgpu offers them as a "reasonable defaults" fallback order so that not everyone has to do this cap check type logic in their apps from what i gather. The logic here is the same as in the wgpu source: these two modes convert to this set of fallbacks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, okay that explains it, thanks.

@IQuick143 IQuick143 added A-Rendering Drawing game state to the screen P-Crash A sudden unexpected crash S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it D-Straightforward Simple bug fixes and API improvements, docs, test and examples labels Dec 13, 2025
@IQuick143 IQuick143 added this to the 0.18 milestone Dec 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Rendering Drawing game state to the screen D-Straightforward Simple bug fixes and API improvements, docs, test and examples P-Crash A sudden unexpected crash S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

4 participants