On Wed, 4 Nov 2026 14:25:19 GMT, Christopher Schnick <[email protected]> wrote:
> In terms of error handling, does the d3d12 backend also handle all the > possible failures like d3d does with D3dContext::testLostStateAndReset? I > didn't see an equivalent handling in the new code. @crschnick Since D3D10 losing the graphics device is considered a much more fatal and non-regular scenario than in was in D3D9. In 9 you had to actually handle it in "standard" situations - switching windowed to fullscreen for example would trigger it, I think also changing Stage dimensions or minimizing/restoring the app could trigger it, then you would have to recreate the Device and used resources. D3D9 backend in JavaFX was built to handle scenarios like these, hence it has much more robust resource tracking on Java-side. In D3D12 losing the device (or as 12 calls it, having your device removed) is a tragic should-not-ever-happen situation and only comes up if there is some sort of API use error on implementation side. In other words, when everything is properly executed and bug-free in D3D12 there should never be a lost/removed device that we would have to manage. Right now there are bits of native code that check device status after calling D3D12 APIs and handle error reporting, including device being lost (see `D3D12NI_DEV_RET_IF_FAILED` in `D3D12Common.hpp` and its uses all over the backend). These are more for us developers to try and chase down potential bugs in the backend and they do hook up to 12's debug facilities like DRED or debug layers. I will say, current error reporting implementation is still not perfect, because ever since introducing the Render Thread (which was a pretty late performance-motivated addition) there was a "I'll tackle this later" problem in form of actually properly reporting D3D12 errors back to main/Quantum thread. I filed it a while ago as [JDK-8388013](https://bugs.openjdk.org/browse/JDK-8388013) and am working on improving this in the background. For now we figured it's a larger change that should be handled separately in an already massive PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2346#issuecomment-6660456662
