"cargo run --package tour" opens a window, but it’s invisible

[loewenheim]

It took me a while to get everything compiling and running under NixOS. I can now compile and run the tour package, but I can’t see or interact with the window that (supposedly) opens. You can see in the attached screenshots that my desktop looks the same whether my terminal or the iced window is focused.

I’m using i3 on nixos-unstable. My graphics card is an onboard Intel device.

[hecrj]

Thanks for reporting!

Could you confirm if the same issue happens when you run any of the winit and/or wgpu examples?

t took me a while to get everything compiling and running under NixOS

If you can provide more details about this process, it may help us find out what the problem is.

[loewenheim]

All the wgpu examples I tried work, but the two winit examples I tried (timer and window_icon) exhibit exactly the same behavior as the iced one.

If you can provide more details about this process, it may help us find out what the problem is.

I wrote a shell.nix file that resides in the base directory of iced (and wgpu, and winit) with the following contents:

{pkgs ? import <nixpkgs> {}, lib ? pkgs.stdenv.lib }:
pkgs.stdenv.mkDerivation rec {
  name = "env";
  nativeBuildInputs = with pkgs; [ pkgconfig ];
  buildInputs = with pkgs; [
    xorg.libX11
    xorg.libXcursor
    xorg.libXrandr
    xorg.libXi
    freetype
    expat
    gperf
    vulkan-headers
    vulkan-tools
    vulkan-loader
  ];
  
  LD_LIBRARY_PATH = "${lib.makeLibraryPath buildInputs}";
}

Then by using nix-shell in the base directory, I’m dropped into a shell where all these dependencies are available and pkgconfig can find them.

[hecrj]

All the wgpu examples I tried work, but the two winit examples I tried (timer and window_icon) exhibit exactly the same behavior as the iced one.

Both of these winit examples don't draw anything. I suspect the window is opened correctly, but nothing is being rendered to it so it stays transparent.

wgpu has evolved quite a bit since 0.4 (the one we use), could you try the examples in the 0.4 branch? As I explained in #243, you will need to change the last line of the Cargo.toml to compile them:

winit = "=0.20.0-alpha4"

[loewenheim]

The wgpu examples still (already?) work in 0.4. Are there any specific winit examples I should test?

[hecrj]

wgpu is using winit for its examples. If they work for you, I believe we can discard any issues there.

My bet is that the current renderer is doing something that is not supported by your graphics driver. I think the vulkan-validation-layers could help us identify the problem. Could you try installing them and then run the tour example in debug mode? Any errors/warnings should be printed in the terminal.

[loewenheim]

How do I run it in debug mode?

[hecrj]

Oh, sorry. I meant you should run it without the --release flag, just as you did in those screenshots.

[loewenheim]

Installing the validation layers does not seem to have made a difference. I’m not seeing any errors or warnings.

[hecrj]

Oh well, I am a bit clueless then. Some more questions worth to answer:

• Does the same issue happen with examples that enable antialiasing, like clock or solar_system?
• Is the window really invisible or is it visible but nothing is being drawn on it? Is there some way for you to find out? Maybe you could enable decorations, change the WM layout, or try moving/resizing the window.
• Could you try the wgpu_glyph examples too?

[loewenheim]

Ok, this is weird. I tried the clock example and initially got these results, in tabbed and split layout, respectively:


I took screenshots and switched over to firefox to write this comment. When I switched back to the desktop with the terminal, the clock had appeared:

This made me try the tour and solar_system examples as well, and … everything works now. I can open the windows, switch the desktop layout, turn them into floating windows, close them. I’m also not experiencing any delays or artifacts.

tour outputs an error, but I don’t know if it has anything to do with all this:

ERROR gfx_backend_vulkan]
    VALIDATION [VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 (0)] : vkCreateSwapchainKHR() called with imageExtent = (1707,1280), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (950,1046), minImageExtent = (950,1046), maxImageExtent = (950,1046). The Vulkan spec states: imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274)
    object info: (type: DEVICE, hndl: 94518417843024)

[hecrj]

Hmm... It feels like we are dealing with some weird driver shenanigans.

I think OpenGL support for wgpu will happen eventually and should solve most of these issues. I am also experimenting with different, more mature rendering alternatives.

tour outputs an error, but I don’t know if it has anything to do with all this

I believe it's unrelated, although probably worthy of further investigation. This error happens when swapchain creation can't keep up with window resize events.

[loewenheim]

In any case, thank you very much for your assistance and for your work on iced, it looks extremely promising!