Windows skia software rendering still requires d3d context

[Vaider7]

Hi, in one of the latest releases there was PR, which enable skia_backend_software for Windows by default. What I actually noticed that building slint app still requires skia d3d feature and Winit window is initialized with new_direct3d_suspended function. This led to querying d3d .dll files on application startup. I faced error missing d3d12.dll file. Afaik software rendering shouldn't depend on d3d context. So I made a little bit of very dirty changes:

diff --git a/internal/backends/winit/renderer/skia.rs b/internal/backends/winit/renderer/skia.rs
index b45772a21..9baefaa30 100644
--- a/internal/backends/winit/renderer/skia.rs
+++ b/internal/backends/winit/renderer/skia.rs
@@ -55,7 +55,7 @@ pub fn new_direct3d_suspended(
         shared_backend_data: &Rc<crate::SharedBackendData>,
     ) -> Box<dyn super::WinitCompatibleRenderer> {
         Box::new(Self {
-            renderer: SkiaRenderer::default_direct3d(&shared_backend_data.skia_context),
+            renderer: SkiaRenderer::default_software(&shared_backend_data.skia_context),
         })
     }

diff --git a/internal/renderers/skia/Cargo.toml b/internal/renderers/skia/Cargo.toml
index d8293c7f0..d61ce278c 100644
--- a/internal/renderers/skia/Cargo.toml
+++ b/internal/renderers/skia/Cargo.toml
@@ -59,7 +59,7 @@ bytemuck = { workspace = true }

 [target.'cfg(target_family = "windows")'.dependencies]
 windows = { version = "0.61.1", features = ["Win32", "Win32_System_Com", "Win32_Graphics", "Win32_Graphics_Dxgi", "Win32_Graphics_Direct3D12", "Win32_Graphics_Direct3D", "Win32_Foundation", "Win32_Graphics_Dxgi_Common", "Win32_System_Threading", "Win32_Security"] }
-skia-safe = { version = "0.86.0", features = ["d3d"] }
+skia-safe = { version = "0.86.0" }

diff --git a/internal/renderers/skia/lib.rs b/internal/renderers/skia/lib.rs
index 05a3a1448..944cb690f 100644
--- a/internal/renderers/skia/lib.rs
+++ b/internal/renderers/skia/lib.rs
@@ -42,8 +42,8 @@
 #[cfg(target_vendor = "apple")]
 pub mod metal_surface;

-#[cfg(target_family = "windows")]
-pub mod d3d_surface;
+// #[cfg(target_family = "windows")]
+// pub mod d3d_surface;

 #[cfg(skia_backend_vulkan)]
 pub mod vulkan_surface;
@@ -321,38 +321,38 @@ pub fn default_vulkan(context: &SkiaSharedContext) -> Self {
         }
     }

-    #[cfg(target_family = "windows")]
-    /// Creates a new SkiaRenderer that will always use Skia's Direct3D renderer.
-    pub fn default_direct3d(context: &SkiaSharedContext) -> Self {
-        Self {
-            maybe_window_adapter: Default::default(),
-            rendering_notifier: Default::default(),
-            image_cache: Default::default(),
-            path_cache: Default::default(),
-            rendering_metrics_collector: Default::default(),
-            rendering_first_time: Default::default(),
-            surface: Default::default(),
-            surface_factory: |context,
-                              window_handle,
-                              display_handle,
-                              size,
-                              requested_graphics_api| {
-                d3d_surface::D3DSurface::new(
-                    context,
-                    window_handle,
-                    display_handle,
-                    size,
-                    requested_graphics_api,
-                )
-                .map(|r| Box::new(r) as Box<dyn Surface>)
-            },
-            pre_present_callback: Default::default(),
-            partial_rendering_state: create_partial_renderer_state(None),
-            dirty_region_debug_mode: Default::default(),
-            dirty_region_history: Default::default(),
-            shared_context: context.clone(),
-        }
-    }
+    // #[cfg(target_family = "windows")]
+    // /// Creates a new SkiaRenderer that will always use Skia's Direct3D renderer.
+    // pub fn default_direct3d(context: &SkiaSharedContext) -> Self {
+    //     Self {
+    //         maybe_window_adapter: Default::default(),
+    //         rendering_notifier: Default::default(),
+    //         image_cache: Default::default(),
+    //         path_cache: Default::default(),
+    //         rendering_metrics_collector: Default::default(),
+    //         rendering_first_time: Default::default(),
+    //         surface: Default::default(),
+    //         surface_factory: |context,
+    //                           window_handle,
+    //                           display_handle,
+    //                           size,
+    //                           requested_graphics_api| {
+    //             d3d_surface::D3DSurface::new(
+    //                 context,
+    //                 window_handle,
+    //                 display_handle,
+    //                 size,
+    //                 requested_graphics_api,
+    //             )
+    //             .map(|r| Box::new(r) as Box<dyn Surface>)
+    //         },
+    //         pre_present_callback: Default::default(),
+    //         partial_rendering_state: create_partial_renderer_state(None),
+    //         dirty_region_debug_mode: Default::default(),
+    //         dirty_region_history: Default::default(),
+    //         shared_context: context.clone(),
+    //     }
+    // }

     /// Creates a new renderer is associated with the provided window adapter.
     pub fn new(

After that launching slint app doesn't require any d3d .dll files. And now it can be used in very old environments. I managed to build slint gallery app for Windows 7 with latest rust (x86_64-win7-windows-msvc target) using winit and skia features. And it works fine!

So my question is maybe it's worth to exclude d3d context till skia_backend_software is enabled?

[tronical]

Thanks for catching this. Perhaps you're running into a bug.

My plan is to re-activate the d3d backend again in the future, but meanwhile if the runtime initializes a d3d context etc just to throw it away again and then use the software renderer, that would be a bug. I think perhaps the bug is in the winit backend.

In terms of runtime and build requirements: I'd like to avoid the complexity of opting out of those, if possible. Would it be acceptable for your target to still require these, but just not use them at runtime?

[Vaider7]

Would it be acceptable for your target to still require these, but just not use them at runtime?

Yes, that's pretty fine. Thanks for reply!