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

Fix initialization of Direct3D swap chain before getting the canvas size #858

Merged
merged 3 commits into from Jan 29, 2024

Conversation

MatkovIvan
Copy link
Member

Currently it fails to init swap chain because the size of the element is zero. It's not valid parameter in DXGI_SWAP_CHAIN_DESC1

[SKIKO] warn: Exception in draw scope org.jetbrains.skiko.RenderException: Native exception in [Java_org_jetbrains_skiko_redrawer_Direct3DRedrawer_initSwapChain], code 3221225477: EXCEPTION_ACCESS_VIOLATION

Fixes JetBrains/compose-multiplatform#4105

@MatkovIvan MatkovIvan merged commit 21d7a12 into master Jan 29, 2024
5 checks passed
@MatkovIvan MatkovIvan deleted the ivan.matkov/fix-d3d-zero-size branch January 29, 2024 11:32
@MatkovIvan MatkovIvan changed the title Don't try to init D3D with zero size Fix initialization of Direct3D swap chain before getting the canvas size Feb 5, 2024
igordmn added a commit that referenced this pull request Mar 6, 2024
Fixes JetBrains/compose-multiplatform#4425

It is a regression after #858

The crash was because `d3dDevice->swapChain->GetBuffer` didn't return the buffer to draw on if we reused the buffer from the previous frame (we didn't change `surface` in case of zero size).

I am not completely sure why, but I exhausted my the investigation limit
and this fix is needed by other reasons (we need vsync on swap buffers).

## Testing
An additional check in the existed test (fails before the fix)
igordmn added a commit that referenced this pull request Mar 6, 2024
Fixes JetBrains/compose-multiplatform#4425

It is a regression after #858

The crash was because `d3dDevice->swapChain->GetBuffer` didn't return
the buffer to draw on if we reused the buffer from the previous frame
(we didn't change `surface` in case of zero size).

I am not completely sure why, but I exhausted my the investigation limit
and this fix is needed by other reasons (we need to wait for vsync).

## Testing
An additional check in the existed test (fails before the fix)
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.

Skiko RenderException
2 participants