The backdrops no longer work in Compose 1.6.x, and I did some debugging to better understand why.
Thought I'd share here since it might be of interest.
On Windows, (generally) the default renderApi will be chosen as Direct3D
In compose 1.5.x, the code to make the SkiaLayer transparent appears to cause the renderer to malfunction, and fall back to the OpenGL (or software) renderer:
[SKIKO] warn: Fallback to next API
org.jetbrains.skiko.RenderException: Failed to create DirectX12 device.
Compose 1.6.x appears to fix the renderer malfunction, so Direct3D is used
There appears to be an issue with the Direct3D renderer, where a black background gets painted behind the rendered content. Curiously, this black background does not resize in sync with the compose content, and so you see a peek of the desired effect before the black box resizes back into place.
You can explicitly request a different renderer (e.g. OpenGL) with System.setProperty("skiko.renderApi", "OPENGL"), and this "fixes" the code on 1.6 -- though it doesn't feel like a good fix. I'd assume that Direct3d is chosen first for a reason.
I believe there are also APIs to set renderer priorities, so the renderer falls back in the most compatible way.
Here's a capture of the black box that obscures the backdrop. Interestingly, this can be defeated by sizing the window to be small and then enlarging it. Something odd going on.
The backdrops no longer work in Compose 1.6.x, and I did some debugging to better understand why. Thought I'd share here since it might be of interest.
Direct3D
SkiaLayer
transparent appears to cause the renderer to malfunction, and fall back to theOpenGL
(or software) renderer:Direct3D
renderer, where a black background gets painted behind the rendered content. Curiously, this black background does not resize in sync with the compose content, and so you see a peek of the desired effect before the black box resizes back into place.You can explicitly request a different renderer (e.g. OpenGL) with
System.setProperty("skiko.renderApi", "OPENGL")
, and this "fixes" the code on 1.6 -- though it doesn't feel like a good fix. I'd assume that Direct3d is chosen first for a reason.I believe there are also APIs to set renderer priorities, so the renderer falls back in the most compatible way.