Skip to content

Add support for builtin DComp swapchains #7550

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

Open
wants to merge 28 commits into
base: trunk
Choose a base branch
from

Conversation

n1ght-hunter
Copy link

@n1ght-hunter n1ght-hunter commented Apr 16, 2025

Connections
#3486
#7108
#5150

Description
add support for builtin DComp swapchains to the dx12 backend.
My main goal for this was to get window transparency to work on windows

Testing
Tested using a basic wgpu app with transparency

Squash or Rebase?
Squash

Checklist

  • Run cargo fmt.
  • Run taplo format.
  • Run cargo clippy --tests. If applicable, add:
    • --target wasm32-unknown-unknown
  • Run cargo xtask test to run tests.
  • If this contains user-facing changes, add a CHANGELOG.md entry.

I dont know if its normal or not but when running cargo xtask test i had 201 tests fail with code 0xc0000005: Invalid access to memory location. (os error 998) this is run on windows 10

@n1ght-hunter n1ght-hunter requested review from crowlKats and a team as code owners April 16, 2025 06:17
Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

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

Generally looking good, some comments.

@cwfitzgerald cwfitzgerald self-assigned this Apr 16, 2025
@n1ght-hunter
Copy link
Author

n1ght-hunter commented Apr 17, 2025

will get to this in the next day or two

@n1ght-hunter
Copy link
Author

@cwfitzgerald would you be able to re review when you get time thanks

Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

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

Sorry for the delay, looks good in general with a few small comments. I also think that the hardcoded list of blending modes needs to be adjusted based on if DXGI or DComp is selected

@Anutrix
Copy link

Anutrix commented May 30, 2025

Might totally be unfounded and not apply here but DirectComposition on Windows has issues with NVIDIA GPU when used with multiple monitors with different and high(60+) refresh rates. This was seen on Firefox so might be specific to it.
Recent ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1968876 . Couldn't find original ticket.

@cwfitzgerald
Copy link
Member

I definitely wouldn't worry about it here. That issue seems to be Windows 10 specific too.

@melody-rs
Copy link
Contributor

Oh! Thank you for doing this, transparency support in wgpu has been a pretty big pain point for me in the past

@n1ght-hunter
Copy link
Author

Im just traveling abroad atm should be able to get to this in the next week or so

@cwfitzgerald
Copy link
Member

Boop :)

@MarijnS95
Copy link
Contributor

So if I understand this correctly, normally one would create and manage a composition (device, target) externally, and pass either the IDCompositionVisual (where wgpu will insert the internally-crated IDXGISwapChain1 as content into the visual) or a HANDLE to an opaque "composition surface" (which the caller should insert as the content of a visual themselves - useful for cross-process sharing) into wgpu surface creation. Allowing users to render into arbitrary surfaces with wgpu while possibly combining it with a much more complicated composition/transformation tree and surfaces filled by other sources.

This PR seems to abstract away the most basic form of that, by creating and managing that DirectComposition device and a single Visual spanning the full Target that wraps the window (where hopefully "someone" disables the backing redirection buffer...) so that users no longer have to deal with it?

i.e. maybe this PR should be retitled and have a better description of what it achieves. Technically "dcomp on Windows" is already supported :)

@n1ght-hunter
Copy link
Author

sorry ended up being very busy. still traveling :). i will be home in about 3 weeks. should have time to work on it then. maybe before but unlikely. if someone else wants to fix it up no worries from me otherwise i will when i get time.

@n1ght-hunter
Copy link
Author

i have updated this pr now. i believe i have fixed all comments except for title of pr.
im terrible with coming up with titles so suggestions are welcome

@cwfitzgerald cwfitzgerald changed the title Add dcomp on windows Add support for builtin DComp swapchains Aug 13, 2025
Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

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

Sorry for another round of comments, we're almost there!

/// Use the DXGI presentation system.
#[default]
Dxgi,
/// Use the DirectComposition presentation system.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
/// Use the DirectComposition presentation system.
/// Use a DXGI swapchain made from a DirectComposition visual made from the window.
///
/// This supports transparent windows, but does not support fullscreen optimization.

Copy link
Contributor

@MarijnS95 MarijnS95 Aug 14, 2025

Choose a reason for hiding this comment

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

@cwfitzgerald these user-facing documentation bits need links to upstream documentation exactly how all this works. Perhaps we need to explain that users cannot or should not use this in conjunction with SurfaceTargetUnsafe::CompositionVisual/SurfaceTargetUnsafe::SurfaceHandle if they're already managing a layer tree externally (themselves).


Can you backup (link) exactly how this doesn't support "fullscreen optimization" (like borderless fullscreen)? I was under the impression that this uses flip-style present as well which should allow for hardware-compositable/presentable planes in the sawpchain?

EDIT: Or are you saying this because translucent surfaces inevitably require the underlying plane(s) to be rendered and blended (hopefully accelerated in hardware by MPO blending) too? If the user disables alpha blending on the swapchain it should still be able to make this optimization.

Copy link
Contributor

Choose a reason for hiding this comment

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

Should we also recommend users to set WS_EX_NOREDIRECTIONBITMAP?

Copy link
Member

Choose a reason for hiding this comment

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

these user-facing documentation bits need links to upstream documentation exactly how all this works. Perhaps we need to explain that users cannot or should not use this in conjunction with SurfaceTargetUnsafe::CompositionVisual/SurfaceTargetUnsafe::SurfaceHandle if they're already managing a layer tree externally (themselves).

I agree, though we can leave this to another PR and spin off an issue from this one, I don't want to hold it up too long as I've already let it sit a while.

Can you backup (link) exactly how this doesn't support "fullscreen optimization" (like borderless fullscreen)? I was under the impression that this uses flip-style present as well which should allow for hardware-compositable/presentable planes in the sawpchain?

I thought I had a conversation about this with Jesse on the d3d12 discord a while ago but I can't find it, so I'll ask again and see what they say.

Should we also recommend users to set WS_EX_NOREDIRECTIONBITMAP?

I honestly don't know.

Copy link
Member

Choose a reason for hiding this comment

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

Re: mpo

I was wrong! Things made from visuals are still eligible for full screen optimization.

@n1ght-hunter
Copy link
Author

@cwfitzgerald done :)

.as_deref()?
.to_lowercase();
match value.as_str() {
"dcomp" => Some(Self::DirectComposition),
Copy link
Contributor

Choose a reason for hiding this comment

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

Also update the argument name?

Copy link
Author

@n1ght-hunter n1ght-hunter Aug 14, 2025

Choose a reason for hiding this comment

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

oh ya was gonna ask we wanted to update that. though i could see leaving it so its short in the cli

Copy link
Member

Choose a reason for hiding this comment

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

I think having both would be reasonable as well.

profiling::scope!("DirectComposition::DCompositionCreateDevice");
unsafe { DirectComposition::DCompositionCreateDevice2(None) }.map_err(|err| {
log::error!("DirectComposition::DCompositionCreateDevice failed: {err}");
crate::SurfaceError::Other("DirectComposition::DCompositionCreateDevice")
Copy link
Contributor

Choose a reason for hiding this comment

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

It's surprising that SurfaceError doesn't have an inner error like InstanceError.

/// Use the DXGI presentation system.
#[default]
Dxgi,
/// Use the DirectComposition presentation system.
Copy link
Contributor

@MarijnS95 MarijnS95 Aug 14, 2025

Choose a reason for hiding this comment

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

@cwfitzgerald these user-facing documentation bits need links to upstream documentation exactly how all this works. Perhaps we need to explain that users cannot or should not use this in conjunction with SurfaceTargetUnsafe::CompositionVisual/SurfaceTargetUnsafe::SurfaceHandle if they're already managing a layer tree externally (themselves).


Can you backup (link) exactly how this doesn't support "fullscreen optimization" (like borderless fullscreen)? I was under the impression that this uses flip-style present as well which should allow for hardware-compositable/presentable planes in the sawpchain?

EDIT: Or are you saying this because translucent surfaces inevitably require the underlying plane(s) to be rendered and blended (hopefully accelerated in hardware by MPO blending) too? If the user disables alpha blending on the swapchain it should still be able to make this optimization.

/// Creates a DirectComposition device and a target for the given window handle.
pub unsafe fn init(hwnd: &HWND) -> Result<Self, crate::SurfaceError> {
let dcomp_device: DirectComposition::IDCompositionDevice = {
profiling::scope!("DirectComposition::DCompositionCreateDevice");
Copy link
Contributor

Choose a reason for hiding this comment

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

Just wondering, is it normal to wrap every external API call - especially these that are well off the hot path - in a profiling scope?

Copy link
Author

Choose a reason for hiding this comment

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

perhaps just a single profile scope for the whole init scope?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah lets do a single scope - generally the decision for what to scope depends on how long it takes, so if there's a single item that takes a long time, scope that, but for processes that only really take a while in aggregate, we can use a single scope.

/// Use the DXGI presentation system.
#[default]
Dxgi,
/// Use the DirectComposition presentation system.
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we also recommend users to set WS_EX_NOREDIRECTIONBITMAP?

@melody-rs
Copy link
Contributor

melody-rs commented Aug 14, 2025

Could we maybe get an example showing how to use DComp to make window transparency work?

Window transparency with wgpu has been a frustration for a while now and having a working example to base things off of would be super helpful imo

@n1ght-hunter
Copy link
Author

Could we maybe get an example showing how to use DComp to make window transparency work?

Window transparency with wgpu has been a frustration for a while now and having a working example to base things off of would be super helpful imo

sure i have a testing example i can its basiclly just a triangle with partly clear background

Co-authored-by: Marijn Suijten <[email protected]>
@cwfitzgerald
Copy link
Member

Could we maybe get an example showing how to use DComp to make window transparency work?

I think we should, but we can do this as a follow up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants