Arch Linux User Repository

The delay when opening files is super annoying, it also seems not to be consistent to work around being able to open files at all.

I first tried the trick with providing the absolute path, but it did not work even after a few minutes. Then I added STL models through the menu multiple times without anything happening.

Then out of a sudden ca. a minute later 2 of the 4-5 models appeared. Here’s the full log:

$ cura /home/dirk/model.stl
qt.qml.typeresolution.cycle: Cyclic dependency detected between "file:///opt/ultimaker-cura/share/cura/resources/qml/Actions.qml" and "file:///opt/ultimaker-cura/share/cura/resources/qml/Actions.qml"
qt.qml.context: file:///opt/ultimaker-cura/share/cura/resources/qml/Settings/SettingView.qml:427:16 Parameter "index" is not declared. Injection of parameters into signal handlers is deprecated. Use JavaScript functions with formal parameters instead.

** (UltiMaker-Cura:362943): WARNING **: 23:59:49.942: atk-bridge: get_device_events_reply: unknown signature

(UltiMaker-Cura:362943): Gdk-WARNING **: 00:01:15.414: Server is missing xdg_foreign support

(UltiMaker-Cura:362943): Gdk-WARNING **: 00:01:20.437: Server is missing xdg_foreign support
"Could not convert argument 0 at"
   "@file:///opt/ultimaker-cura/share/cura/resources/qml/Menus/RecentFilesMenu.qml:33"
"Could not convert argument 0 at"
   "@file:///opt/ultimaker-cura/share/cura/resources/qml/Menus/RecentFilesMenu.qml:33"
"Could not convert argument 0 at"
   "@file:///opt/ultimaker-cura/share/cura/resources/qml/Menus/RecentFilesMenu.qml:33"
"Could not convert argument 0 at"
   "@file:///opt/ultimaker-cura/share/cura/resources/qml/Menus/RecentFilesMenu.qml:33"
"Could not convert argument 0 at"
   "@file:///opt/ultimaker-cura/share/cura/resources/qml/Menus/RecentFilesMenu.qml:33"
Line widths other than 1 are not supported by the graphics API

(UltiMaker-Cura:362943): Gdk-WARNING **: 00:01:40.922: Server is missing xdg_foreign support

This is independent from uwing X11 ode Wayland. I used Wayland (labwc). My cura startup setup:

$ type cura
cura is hashed (/usr/local/bin/cura)

$ cat /usr/local/bin/cura
#!/bin/bash
/usr/bin/cura -platformtheme gtk3 "$@"

Just tested on a modern AMD graphics laptop. Only by rotating the empty bed I could see framerate differences. pkgrel4 is more smoother.

I have both vulkan-radeon and amdvlk, and it's possible that amdvlk might be the default? That might account for the difference if it is.

So far the problem the fix addresses only seems to affect nvidia users, so let's hold tight and limit it to that subset of users until someone with amd or intel reports otherwise.

Thanks again for the report, as well as your offer to test!

That ZINK error seems to be caused by an incompatible Vulkan driver. Are you using vulkan-radeon as well? If the fix would bring an advantage to AMD users as well and there is something I could test, let me know.

@bioxz: Thanks for the report! I wonder why it didn't kill performance on my RDNA2 card. Either way, I'm pushing an update that limits the fix to nvidia users.

The latest change broke Cura for me. The performance is abysmal. Directly calling "/opt/ultimaker-cura/AppRun" is fine, but the new command with environment parameters looks like it makes the 3D rendering running on CPU. I'm unable to view complex models.

I'm using Wayland + KDE on a Radeon RDNA2 GPU with the amdgpu driver and vulkan-radeon for Vulkan. During the start with the new parameters I get

MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
libEGL warning: egl: failed to create dri2 screen

@sausix: Thanks for testing, and those concerns are valid. For now I've updated the script to include mesa as an optional dependency (with an explanation that it's required for use with the closed source nvidia driver + wayland), and added a test to ensure /usr/share/glvnd/egl_vendor.d/50_mesa.json exists before going that route.

If people run into issues I can also check for the nvidia module, but this current method works with the open source amd driver so I suspect it'll probably be fine in most/all situations.

Cheers!