Godot: Godot lent à ouvrir, lent à modifier, lent à lancer un jeu simple [Windows, causé par des périphériques USB spécifiques]

NVIDIA, hein? Je crois qu'il y a eu des rapports de lancements lents sur NVIDIA, vous pouvez essayer de rechercher «NVIDIA» dans les problèmes. Le consensus final était qu'il y avait un bogue de pilote.

nVidia GeForce GTX 1060 6 Go / PCIe / SSE2 ici, Godot 3.0.6 s'ouvre très bien pour moi (site Web version non mono). Je sais que Godot est légèrement plus lent dans certains cas avec nVidia en raison de mauvais modes de performance automatique, mais pas si lent (comme dans le lancement de 30 secondes au lieu de 4).

GTX 960 et 1070 rapportant les mêmes problèmes. Lancement lent dans Windows, rapide sous Linux.
Je souhaite vraiment que cela puisse être corrigé, car c'est mon plus gros problème avec Godot. J'aime lancer mon jeu tout le temps pour tester de petits ajustements, mais prend trop de temps dans Windows avec mes GPU nvidia.

Rejoindre le problème avec une GTX 1070. J'ai essayé toutes les versions stables de Godot. Également essayé sur 3 versions du dernier pilote 398.98, 398.82, 398.36. Mais j'ai remarqué que la première fois (après la réinstallation du pilote, le redémarrage de l'ordinateur), il a démarré rapidement. Je jouerai avec certains paramètres de Nvidia lorsque je trouverai le temps. C'est un gros problème et devrait être recherché un peu plus.

Edit: Je reconfirme que le premier démarrage après un redémarrage du système fonctionne normalement. Chaque démarrage suivant prend du temps (40 s).

https://www.nvidia.co.kr/Download/driverResults.aspx/137317/en
Le pilote 399.07 est publié.
testeriez-vous avec?

Hey volzhs - oui cela semble l'avoir réglé!
Je n'ai pas encore eu le temps de faire des tests approfondis, mais vient d'ouvrir / éditer / exécuter quelques jeux et les performances étaient excellentes.
Merci pour les informations sur le dernier pilote.

Je ne sais pas comment cela affecte mais la note de version du pilote contient cela.

[GeForce GTX 1050/1070]: le pilote OpenGL ne libère pas le contexte de rendu
correctement. [2305430]

Super trouvaille @volzhs , merci :)

@fossegutten @cimpresovec La mise à jour vers 399.07 résout-elle également le problème de vos cartes?

En fait, j'ai récemment fait un formatage complet de mon PC et le problème a disparu avec le même pilote (398,98). J'ai essayé le nouveau pilote aujourd'hui et le problème ne s'est pas produit. Alors je ne sais pas quoi dire. Même pilote avant et après format mais comportement différent. Je ne peux pas dire ce qui a causé le problème dans l'installation précédente, mais cela m'a dissuadé d'utiliser Godot.

Malheureusement, cela a recommencé à se reproduire pour moi. Godot fonctionne correctement pendant environ 1 heure, puis recommence à fonctionner lentement.

La chose vraiment étrange est que si je redémarre mon PC, Godot fonctionne à nouveau bien pendant un moment, mais commence ensuite à ralentir.
Cependant, je suis maintenant presque sûr que ce n'est pas un problème Godot. Pourrait essayer de mettre la main sur une carte AMD et voir si cela élimine le problème pour de bon.

GTX750 ici; Je pensais que cela avait quelque chose à voir avec https://github.com/godotengine/godot/issues/21472#issuecomment -416151678 ne construisant pas avec sse2, car j'étais nouveau dans la construction, mais ce problème ne semble s'être aggravé que par le ces dernières semaines, la 3.1a1 ayant les temps de chargement les plus longs à ce jour.

J'utilise actuellement le pilote 399.07.

Edit: Peut-être pas un problème de GPU? Remarqué une utilisation extrêmement élevée du processeur et une faible utilisation du GPU pendant ces temps de chargement lents. Prenant environ 27% de CPU (allocation d'un thread matériel entier sur mon CPU), tombe à des niveaux normaux une fois le chargement terminé.

Edit2: Non lié à ce problème, j'ai déposé un autre problème.

Désolé de la réponse tardive. Toujours super lent, avec le pilote 399.24 sur le GPU GTX 1070.

Le problème est de retour pour moi. Eh bien, je l'ai remarqué lors du développement d'une autre application avec la bibliothèque Raylib (utilise GLFW en dessous). L'application a montré le même comportement que Godot. J'ai ensuite téléchargé Godot et le problème était de retour. J'ai remarqué qu'après un redémarrage du système, tout fonctionne normalement, même après plusieurs exécutions séparées. Le problème commence à se produire après un certain temps (sans test) ou après avoir exécuté des jeux plus lourds sur le système, puis essayé d'exécuter Godot. Unity, en revanche, n'est pas affecté mais je n'ai pas essayé Defold.

Qu'est-ce que GLFW et Godot pourraient avoir en commun?

Les deux utilisent OpenGL sous le capot. Tout comme certains autres programmes que j'ai mentionnés qui ne présentent pas le problème.

Le problème semble être Open GL oui. Monogame a le même comportement avec les projets OpenGL, mais pas avec les projets Direct X.

Hmm, si le problème existe pour toutes les choses OpenGL, alors ce sont probablement des pilotes de GPU de merde.

Le comportement n'est pas cohérent entre les différentes applications OpenGL. Certains fonctionnent très bien (versions Unity OpenGL, moteur Defold, etc.). Cela dépend probablement de la version utilisée, mais ce ne sont que de pures spéculations. Je ne peux malheureusement pas apporter d'aide concrète.

même problème ici, des conseils?

Mon temps de démarrage n'est pas de l'ordre de 30 secondes et plus, mais d'environ 5 à 10 secondes. C'est définitivement plus lent qu'il ne devrait l'être. J'ai essayé cela avec un exécutable exporté et dans le moteur. Cela se produit également avec GLES3 et GLES2.

J'utilise une GTX 1080 sur le pilote 416.16
Je mettrai à jour le pilote momentanément et je reviendrai avec une note sur tout changement.

Edit: Le problème persiste avec le pilote 416.34, et (peut-être sans rapport) il semble un peu lent de démarrer Godot lui-même, ainsi que d'ouvrir un projet.

Je suis sous Linux et j'utilisais les pilotes NVIDIA 390.87. Il semblait vraiment qu'il fonctionnait sur le rendu logiciel depuis l'utilisation élevée du processeur lors du défilement par exemple.
J'ai installé les pilotes NVIDIA 410.73 et tout va bien maintenant. Je ne sais pas si NVIDIA a résolu ces problèmes ou simplement réinstaller les pilotes a aidé

J'ai aussi essayé sous Linux, et Godot semble bien fonctionner. C'est encore lent sous Windows.

J'ai aussi essayé sous Linux, et Godot semble bien fonctionner. C'est encore lent sous Windows.

Quelle version de Linux utilisez-vous? Et l'utilisez-vous dans une VM?

Arch Linux. Pas de VM.

Ici, à @JavaryGames, nous vivons cela avec tous les ordinateurs, certains avec 1050Ti et certains avec un 1060. Même avec le dernier pilote (417).

Sous Linux, les mêmes machines fonctionnent correctement, c'est donc très probablement un problème de pilote.

Je pense que je pourrais rencontrer ce problème également sur Windows 10 godot 3.0.6

J'ai cependant un AMD RX 580

Ajout de mes propres points de données:

Processeur Intel i7-3770K
16 Go de RAM
Windows 7

1. Ce problème concerne 3.06-stable_win64 et 3.1-alpha5_win64. Il faut 30 secondes à 1 minute pour charger le moteur ou lire une scène.
2. Cela peut être corrigé en redémarrant l'ordinateur, mais revient toujours après plusieurs scènes de lecture. Peut être lié à des accidents de moteur / scène.
3. Ce problème se produit à tout moment [une fois qu'il commence après un bref redémarrage 'cure'] la fenêtre Godot Engine Editor (avec sortie de terminal) à chaque fois que "OpenGL ES [X] .0 Renderer" apparaît. Donc, quand l'exécutable démarre, et lorsqu'une scène est exécutée.
4. Cela ne dépend pas du pilote ou du GPU. J'ai utilisé un RX480 avec des pilotes mis à jour et un GTX 1070 avec des pilotes mis à jour. Le problème n'a pas changé. Si ce

Avoir cela aussi sur une Nvidia GTX 1070

Windows uniquement, s'ouvre et fonctionne correctement sous Linux.

J'ai le même problème, mais sur Linux avec un GPU AMD. J'ai du mal à le suivre, car cela a commencé à se produire après une mise à jour du système, mais la rétrogradation ne l'a pas résolu. le déclassement de godot n'a eu aucun effet non plus. cela prend plus de 30 secondes pour ouvrir mon projet, plus de 30 secondes pour le démarrer, et il bégaye (parfois se fige pendant un certain temps) chaque fois qu'un nouvel objet est affiché à l'écran pour la première fois. dans l'éditeur, les opérations de base comme cliquer sur un nœud ou ouvrir une scène prennent souvent plus de 30 secondes.

quand les choses sont figées, le son est toujours joué, godot utilise 100% du processeur sur un cœur, et ni godot ni dmesg ne montrent une seule erreur. au début, je pensais que cela pouvait provenir de la compilation de shaders, et si l'utilisation de l'éditeur de shader et le laisser compiler peut provoquer un gel de 30 secondes, cela ne semble pas le faire après la première fois que cela se produit.

dans mon cas, cela semble quelque peu aléatoire, soit un bégaiement de 10 images, soit plus de 30 secondes sans intermédiaire. il disparaît presque toujours après le chargement d'une chose, mais ce comportement se réinitialise lorsque godot est fermé / rouvert, un redémarrage ne l'affecte pas.

Votre Linux Mint ou Arch est-il par hasard?

@retrotails Sonne comme # 24783.

@retrotails Sonne comme # 24783.

oh merci, semble-t-il. Je n'ai que 18.2 en cache, et cela se produit toujours sur 18.2 mais beaucoup moins sévère. va essayer de compiler la dernière mesa et voir si elle est au moins corrigée là-bas.

Aux personnes concernées par ce problème: pouvez-vous essayer Godot 3.1 beta 2 (ou version ultérieure) et voir s'il se comporte toujours de la même manière?

Les premiers tests indiquent que la version 3.1 beta 2 a résolu le problème pour moi. Je mettrai à jour s'il recommence à fonctionner lentement. Merci d'avoir réglé ce problème.

Non, la version 3.1 beta 2 a encore des problèmes intermittents sur mon gtx 1070. Parfois c'est rapide, d'autres fois c'est trop lent. Remarque Je n'ai aucun problème sur mon ordinateur portable p52 fonctionnant également sous Windows, avec une carte quadro p2000.

Bonjour,
même problème ici:
Accueil Windows 10 x64
processeur: AMD Ryzen 5 2600X
GPU: AMD Rx580

Après un nouveau démarrage informatique, Godot mettra 30/40 secondes pour ouvrir, charger ou exécuter un projet ...
Peu importe la version de Godot (2.x, 3.0.x, 3.1 alpha x ou beta x)
Après avoir redémarré l'ordinateur, tout fonctionne bien pour autant que je sache

J'ai essayé de désactiver le démarrage / démarrage rapide sur Windows, mais le problème n'est pas résolu.
Je suis vraiment confus car tout allait bien il y a quelques jours / semaines ...

Cependant, je suis presque sûr que ce n'est pas directement un problème Godot. J'ai remarqué, par exemple, que le client STEAM a le même comportement que Godot (et certains jeux ne fonctionnent pas du tout) lorsque le problème survient.

Moi encore:

Processeur Intel i7-3770K
16 Go de RAM
Windows 7

Maintenant sur 3.1 Beta 2, les intervalles de ~ 30 secondes commencent immédiatement, sans la période normale de lune de miel après un redémarrage où les choses vont vite.

Bonjour, _ [Godot v3.0.6 - WIN 10 - GTX 1060 3 Go - 16 Go de RAM DDR3 - Intel i5-4460] _

Même problème ici mais sans crashs de Nvidia ou commentaires dans la console.

Le chef de projet met beaucoup de temps à s'ouvrir lorsque je clique sur modifier la même chose, et si j'ai de la chance, je peux à peine entrer dans l'éditeur, où il faut des années pour cliquer sur play et m'attendre à ce qu'il fonctionne correctement.

Dans le gestionnaire de tâches, je découvre que Godot utilise <1% de mon CPU et la même chose avec la RAM. Ce n'est pas mon ordinateur parce que parfois il fonctionne comme prévu, tout est couramment et parfois ce problème apparaît.

J'ai également des problèmes avec le chef de projet essayant de charger un png pour l'afficher sous forme d'icône, et j'ai à nouveau ralenti mon Godot.

Question complètement indépendante, est-ce que l'un d'entre vous ayant ce problème sous Windows exécute une sorte de logiciel antivirus / antimalware? Peut-être que quelque chose scanne le binaire lors de son exécution.

Voici d'autres choses que vous pouvez essayer, peut-être que cela est lié au cache OpenGL, NVidia stocke ceci ici:
C: \ Utilisateurs \\ AppData \ Local \ NVIDIA \ GLCache

Si vous supprimez les fichiers ici, pouvez-vous toujours reproduire le problème?

Enfin, quelque chose que j'ai trouvé sur les forums nvidia, pouvez-vous essayer d'exécuter Godot manuellement tout en définissant cette variable d'environnement? comme:

__GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1
godot.exe

reduz: J'ai essayé ça. Cela n'a rien changé.

@ ay200 Avez-vous nvidia?

@reduz Oui, 1070GTX.

J'ai eu une ouverture très lente aussi, mais je corrige cela en supprimant le fichier: %appdata%/Godot/editor_settings-3.tres c'était vraiment gros (~ 100 Mo ou plus, je ne me souviens pas). Cela aidera peut-être.

J'ai eu le même problème, et finalement j'ai eu dans Paramètres du projet -> Débogage -> Paramètre -> "Forcer FPS" mis à 1 :) Le paramétrer sur 0 a résolu le problème. Il suffit de poster ici, car c'est le premier lien avec un retard trouvé.

Désolé les gars, j'ai le sentiment que ce problème devient une salade de problèmes différents.

Gros fichier de configuration:

Si l'un de vous est affecté par la lenteur d'ouverture du CHEF DE PROJET ET DE L'ÉDITEUR et par hasard
% appdata% / Godot / editor_settings-3.tres est énorme, VEUILLEZ LE ZIP ET L'ENVOYER afin que nous puissions savoir pourquoi ce fichier est énorme. Si, pour une raison quelconque, cela contient des informations privées, veuillez d'abord les modifier pour les supprimer (même si je ne pense pas vraiment que cela enregistre pour peut-être des chemins vers vos projets).

Lancement du jeu lent

Si votre JEU est lent à démarrer, mais que le chef de projet et l'éditeur sont OK. Veuillez décrire votre matériel, y compris la version du système d'exploitation, du GPU et du pilote.

Lancement du jeu lent

Si votre JEU est lent à démarrer, mais que le chef de projet et l'éditeur sont OK. Veuillez décrire votre matériel, y compris la version du système d'exploitation, du GPU et du pilote.

Selon le même # 23986, il semble être corrigé dans le dernier pilote Nvidia (419.17 sur Windows 10). Certains d'entre vous peuvent-ils le confirmer?

J'ai ce même problème.

Prend environ 41 secondes pour le lancement initial, l'ouverture du projet et l'exécution (j'ai chronométré chacun individuellement et ils étaient tous à moins d'une seconde l'un de l'autre).
Le redémarrage l'a corrigé.

J'ai essayé la v3.0.6 à la fois non mono et mono et le même problème avec les deux. C'est aussi avec le projet de tutoriel super basique "instancing".

Spécifications:
Windows 10 (64 bits)
AMD Radeon HD 6700 (v15.201.1151.1008)
16 Go de RAM

EDIT: Je commence à utiliser la version bêta 3.1 et il semble l'avoir corrigé, mais le temps nous le dira. Je mettrai à jour ceci s'il revient.

Je viens d'avoir ce problème de nulle part maintenant ... puis je me suis souvenu que je venais de mettre à jour mes pilotes NVidia et que j'avais oublié de désactiver la télémétrie ( https://github.com/NateShoffner/Disable-Nvidia-Telemetry ) après avoir fait cela et redémarré, Godot a démarré très bien. C'est vraiment très intéressant ... (Windows 10 x64 v1809)

Quelqu'un a-t-il essayé cela peut-être? Je pense que cela a quelque chose à voir avec ces trucs de télémétrie. J'utilise également les derniers pilotes Nvidia:

J'ai toujours le même problème.

Prend vraiment beaucoup de temps à lancer au départ, puis à ouvrir le projet. La seule fois où cela a bien fonctionné, c'est lorsque j'ai initialement téléchargé Godot, mais une fois que le problème des longs temps de chargement a commencé, il n'y a aucun moyen de le faire fonctionner à nouveau.

Se produit à la fois sur Godot v3.1 et v3.1.1 (tous deux non mono)

J'ai essayé toutes les suggestions ici et n'aide pas.

Spécifications:
Windows 10 (64 bits)
Nvidia RTX 2070 (v430.39)
16 Go de RAM

Suite à la suggestion de teihoo en désactivant la télémétrie, cela fonctionne après le redémarrage. Mais une fois que vous redémarrez, il est à nouveau lent. Réactiver la télémétrie, puis la désactiver ne résout pas à nouveau le problème. Je nettoie installé mon pilote Nvidia v430.39 et il fait la même chose avec un travail une fois après le redémarrage, mais ne fonctionne pas après le deuxième redémarrage. Je suis passé au pilote de créateur Nvidia au lieu du pilote prêt pour le jeu et le problème persiste. J'ai essayé la version Steam juste pour m'en assurer et le problème est toujours présent. J'espère vraiment que ce problème pourra être résolu.

Je me demande pourquoi le titre du numéro a été changé ..? Puisqu'il ne semble pas être un problème uniquement Nvidia.

Le problème est toujours là pour moi (AMD RX580 - Version des paramètres Radeon: 2019.0326.2353.42986 - Version OpenGL: 25.20.15000.13547 - Version API OpenGL: 4.6)

Le problème est toujours présent pour moi. Maintenant sur le pilote Nvidia v430.64. Ne fonctionne toujours pas.

Certainement un problème OpenGL et non spécifique à Godot, ou à Nvidia ou AMD d'ailleurs. Même un projet MonoGame vierge prend très longtemps à s'ouvrir.

Salut!
Tout fonctionnait bien, puis j'ai mis à jour mes pilotes nvidia à 430.64.

Depuis lors, lorsque je lance le jeu via F5 / F6, le démarrage est vraiment lent (presque une minute).

Voici ma configuration:
Windows 10 Professionnel 64 bits
16go DDR4
Geforce GTX1060 6Gb
Fonctionnement sur un SSD

J'ai besoin d'exécuter le double démarrage avec Ubuntu juste pour travailler avec Godot de manière efficace. Juste un conseil pour les autres lutteurs!

Salut les gars, j'ai un problème similaire, mais cela n'arrive qu'avec la 3.1.1, une autre version est bien.

Voici ma spécification de pomme de terre:
Windows 10
GPU: nVidia GeForce GT 520M
Version du pilote: 391.35 (je suis coincé avec cette version, pas de pilote plus récent disponible pour 520M)

Oui, ce n'est pas une machine puissante, mais c'est assez décent. Je peux exécuter Unity en douceur, même si je peux jouer à des jeux portés sur ps3 à partir de Steam avec un FPS complet. Donc, courir Godot devrait être un jeu d'enfant.

Lorsque j'utilise 3.1.1 Après avoir joué au jeu depuis l'éditeur, mon ordinateur portable a ralenti, cette condition persiste même après la fermeture de Godot.
C'est un ralentissement très important qui rend mon ordinateur portable inutilisable. Si je force à l'utiliser finalement, cela devient pire et un écran noir et un artefact sur mon écran (pendant plusieurs minutes). J'ai très peur, ça me donne la chair de poule.
La seule façon de résoudre ce problème est de redémarrer Windows.

Alors maintenant, j'utilise 3.1 il fonctionne bien, un petit hoquet se produit lorsque je joue au jeu depuis l'éditeur, mais c'est à peine perceptible.

C'est tout. J'espère que cela aidera à résoudre ce problème.

Re-bonjour,

Je viens de formater l'ordinateur et je viens d'installer Godot. La dernière version 3.1.1 x64. Et quand je l'ai ouvert pour la première fois, ce problème m'est arrivé.

Spécifications du PC:
GPU: Nvidia 1060 3 Go [Avec de nouveaux pilotes propres installés]
Processeur: Intel i5-4460
Mémoire vive: 16 Go de DDR3
Système d'exploitation: WIN10

J'ai regardé le fichier .tres et il n'a obtenu que 5 Ko.
Et la console dit "OpenGL ES 3.0 Renderer: GeForce GTX 1060 3GB / PCIe / SSE2."

J'ai eu ce problème il y a longtemps et il n'est pas lié à NVIDIA. J'ai eu un problème il y a quelques temps, mes pilotes USB n'étaient pas installés correctement. Godot semble être à la traîne mais tout est toujours réactif. cela se produisait lors du chargement de projets et lorsque j'essayais de lancer le jeu dans l'éditeur Godot.

Godot essaie de vérifier tous les périphériques USB connectés pour voir s'il s'agit d'un clavier, d'un contrôleur de jeu, d'un casque VR, etc. si le contrôleur / pilote USB n'est pas installé correctement, il attendra jusqu'à une minute. Après cette minute, il lancera le jeu de débogage ou chargera des projets.

la réinstallation de vos pilotes résoudra le problème. J'ai trouvé cette information en postant sur godot discord il y a quelques années. J'espère que cela aide. Deux personnes ont même signalé ce problème sur ma diffusion en direct. Mes informations ont aidé beaucoup.

En ce qui concerne les projets de monogame, oui, il se produira tout ce qui vérifie les contrôleurs de jeu ou les périphériques USB. Monogame vérifie également les périphériques USB.

J'ai eu le même problème que d'autres personnes mentionnées. Au démarrage de Windows, Godot 3.1.1 fonctionnait bien au début, mais après un certain temps, le démarrage de Godot, le chargement des projets et la lecture d'un projet prendrait environ 30 secondes.

Pour moi, c'était aussi à cause d'un périphérique USB (comme l'a dit shmellyorc). Cet appareil USB était un hub USB, qui connectait mon M&K à mon PC. Cependant, je n'ai réinstallé aucun pilote, j'ai juste connecté directement mon M&K à mon PC. Cela a corrigé tous les ralentissements (je n'avais même pas besoin de redémarrer Godot ou mon PC).

Peut confirmer que j'ai le même problème. J'ai un PC assez récemment installé, réinstallé en mai, avec juste quelques programmes installés et j'obtiens le même démarrage lent de Godot, ouverture de projets et lecture de scènes depuis l'éditeur.

Mes projets sont minuscules, car je viens de commencer le cours Discovering Godot sur Udemy et jusqu'à présent, j'ai simplement imprimé du texte sur la console de sortie de Godot.

Mon% appdata% / Godot / editor_settings-3.tres ne fait que 8 Ko, donc je n'appellerais pas ça énorme.

J'ai essayé de désactiver la télémétrie Nvidia, redémarré mon PC et tout est rapide et agréable.

Win 10, version 1903, build 18362.10005
GFX: MSI 970GTX, le dernier pilote Nvidia
Mémoire RAM: 16 Go
Processeur: i7-4790
USB: Corsair KB & Mouse, carte son Focusrite Scarletti, manette Xbox, dongle iLok

J'utilise également la même version de Godot sur un vieux Thinkpad T420 avec Win10 et probablement dans une carte graphique Intel interne. Là, cela fonctionne parfaitement.

J'ai un problème similaire, mais je n'appellerais pas cela des ralentissements, mais en fait suspendu, alors que le processeur augmente de 80%. Je ne suis donc pas sûr que mon problème soit le même, car je n'ai pas de NVIDIA, et godot se bloque pour des actions très spécifiques et seulement jusqu'à un certain point, comme je l'expliquerai ci-dessous, et uniquement dans GLES3 et uniquement en 3D . Après cela, tout semble beau et lisse. Le lancement d'un jeu est instantané avec un projet vide.

Tout d'abord, j'utilise Godot 3.1.1 stable, et mon système est:
Windows 7
Série ATI Radeon HD 4800 (1 Go de mémoire, iirc)
Intel Core Duo 2.13Ghz (deux cœurs, avec OC à 3,6Ghz)
2 Go de RAM

J'ai eu ce problème depuis la sortie de la version 3.0. J'ai demandé autour de moi et j'ai été amené à croire que ma carte gfx pourrait ne pas prendre en charge GLES3. Je viens de lancer GLView maintenant, et sous GL Report il répertorie plusieurs versions 3.x à 100% . Peut-être que quelqu'un peut me confirmer que cela signifie que GLES3 est entièrement pris en charge par ma carte?

Donc, à propos des trucs suspendus, ça va comme ça:

        hanging times

launching godot                   - 38 seconds
placing the root Spatial          - 54 seconds
placing a 2nd different node      - 54 seconds
placing a 3rd different node      - 18 seconds
placing every next random node    - instantaneous. From now on all seems smooth.

Le fait est que les temps de suspension sont les mêmes chaque fois que j'essaye ceci, donnez ou prenez une seconde, ni plus ni moins - c'est presque exact. J'ai remarqué une exception étrange: si le 2ème nœud différent que je place est un Sprite3D il est placé instantanément, mais alors les 3ème et 4ème nœuds que je place prennent les mêmes temps que les 2ème et 3ème ci-dessus.

Une autre chose que j'ai remarquée, c'est qu'après avoir placé la racine Spatial, je peux placer Spatials tout ce que je veux sans aucun accrochage. C'est lorsque je place un nœud 3D différent qu'il se bloque une fois de plus. La même chose est vraie pour chaque nœud spécifique que je place ensuite, quel que soit mon choix: donc si le prochain que je choisis est un CSGBox, il se bloque 54 secondes, puis je peux placer des CSGBox au contenu de mon cœur sans accrocher ... jusqu'à Je place le 3ème nœud différent.

(EDIT: et btw, si je traite avec des scènes que j'ai déjà construites auparavant, la simple sélection des nœuds après le démarrage bloque le moteur dans le même modèle)

La suppression de l'environnement par défaut bloque godot pendant 72 secondes la première fois. Ensuite, je peux le remettre et le retirer sans problème. Le passage de la vue 2D à la vue 3D prend également un certain temps la première fois (je ne l'ai pas chronométré).

Dans GLES2, godot me prend environ 11 secondes pour démarrer, et tout est fluide et instantané à partir de là, y compris la suppression du def. env. (bien qu'il soit encore considérablement plus lent que Godot 2, comme je l'ai mentionné dans # 27230).

De plus, j'obtiens toutes ces erreurs dans la sortie standard au démarrage (cela est répertorié assez rapidement, seulement alors il se bloque apparemment inactif pendant 38 secondes):

OpenGL ES 3.0 Renderer: ATI Radeon HD 4800 Series
ERROR: initialize: Condition ' status != 0x8CD5 ' is true. Continuing..:
   At: drivers/gles3/rasterizer_scene_gles3.cpp:5037

 [... same error 29 more times ...........]

ERROR: initialize: Directional shadow framebuffer status invalid
   At: drivers/gles3/rasterizer_scene_gles3.cpp:5062
ERROR: audio_device_init: Condition ' hr != ((HRESULT)0x00000000) ' is true. returned: ERR_CANT_OPEN
   At: drivers/wasapi/audio_driver_wasapi.cpp:217
ERROR: init: WASAPI: init_render_device error
   At: drivers/wasapi/audio_driver_wasapi.cpp:404

(Les dernières erreurs WASAPI sont probablement dues au fait que je n'ai pas de carte son.)

@Skaruts Godot n'utilise pas OpenGL ES sur les plates-formes de bureau. Au lieu de cela, il utilise OpenGL 3.3 directement (ou OpenGL 2.1 lors de l'utilisation du backend GLES2).

Les anciennes cartes graphiques AMD sont assez mauvaises en termes de prise en charge d'OpenGL, ce qui est à l'origine d'erreurs telles que ERROR: initialize: Directional shadow framebuffer status invalid (https://github.com/godotengine/godot/issues/27572).

J'ai eu ce problème il y a longtemps et il n'est pas lié à NVIDIA. J'ai eu un problème il y a quelques temps, mes pilotes USB n'étaient pas installés correctement. Godot semble être à la traîne mais tout est toujours réactif. cela se produisait lors du chargement de projets et lorsque j'essayais de lancer le jeu dans l'éditeur Godot.

Godot essaie de vérifier tous les périphériques USB connectés pour voir s'il s'agit d'un clavier, d'un contrôleur de jeu, d'un casque VR, etc. si le contrôleur / pilote USB n'est pas installé correctement, il attendra jusqu'à une minute. Après cette minute, il lancera le jeu de débogage ou chargera des projets.

la réinstallation de vos pilotes résoudra le problème. J'ai trouvé cette information en postant sur godot discord il y a quelques années. J'espère que cela aide. Deux personnes ont même signalé ce problème sur ma diffusion en direct. Mes informations ont aidé beaucoup.

En ce qui concerne les projets de monogame, oui, il se produira tout ce qui vérifie les contrôleurs de jeu ou les périphériques USB. Monogame vérifie également les périphériques USB.

Merci, j'ai confirmé que le problème sur les ordinateurs Windows était que les pilotes USB n'étaient pas correctement installés, j'ai installé un nouveau concentrateur d'extension USB sur mon ordinateur et l'éteindre a résolu mon problème.

Confirmé que la déconnexion du concentrateur USB a également résolu le problème pour moi.

Je peux également confirmer que ce problème est lié à certains de mes ports USB2 (déconnecter mon contrôleur USB ou simplement le connecter à un autre port USB3 résout le problème).
merci à tous d'avoir souligné cela.

J'ai eu exactement le même problème et je l'ai résolu en débranchant le deuxième câble USB de mon clavier, qui était destiné aux deux ports USB intégrés. À un moment donné, si jamais j'ai l'intention d'utiliser ces ports, je peux essayer de réinstaller ses pilotes et de le rebrancher.

Je me demande s'il est possible de définir un drapeau dans Godot pour que les manettes de jeu se mettent à jour manuellement (par demande explicite du code)? Ce n'est pas très cool de demander à tous les joueurs concernés de (dés) installer les pilotes USB pour le jeu qui ne se soucie pas réellement des pilotes USB.

Je viens d'installer Godot v3.1.2.stable.official (à partir de Steam).

Win 10, version 1903, build 18362.535
GFX: NVIDIA GeForce RTX 2080 Max-Q (driver 441.66)
RAM: 32GB
CPU: i7-9750
USB: Corsair Keyboard and Razer Mamba mouse

Le lancement de Godot prend 35 secondes. Une fois ouvert, le lancement d'une «application HelloWorld» (rien d'autre qu'un seul nœud) prend 30 secondes. J'ai essayé toutes les suggestions faites par les précédents commentateurs en vain. J'ai essayé la version autonome et je vois le même résultat.

REMARQUE: il peut être utile de faire précéder chacune de ces lignes d'un horodatage:

Godot Engine v3.1.2.stable.official - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce RTX 2080 with Max-Q Design/PCIe/SSE2
Editing project: C:/Users/reed/dev/Godot/HelloGodot (C:::Users::reed::dev::Godot::HelloGodot)
Godot Engine v3.1.2.stable.official - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce RTX 2080 with Max-Q Design/PCIe/SSE2
erasing D:\SteamGames\Steam\steamapps\common\Godot Engine/editor_data/projects/HelloGodot-fa02d82fa570fbe2be598d4aa480ceae/filesystem_update4

@rmangino Puisque vous semblez avoir un ordinateur portable Optimus, cela se produit-il si vous forcez Godot à fonctionner sur des graphiques intégrés? Cela peut être fait en cliquant avec le bouton droit sur l'exécutable et en choisissant le GPU.

REMARQUE: il peut être utile de faire précéder chacune de ces lignes d'un horodatage:

Je ne vois pas de cas d'utilisation réel à ajouter cela - cela n'aiderait pas à résoudre le problème en question ici. Les utilitaires de journalisation ajoutent généralement des horodatages eux-mêmes de toute façon:

@Calinou J'étais ingénieur senior à la fois dans l'équipe Visual Studio chez MS et dans l'équipe Xcode chez Apple. Utiliser généreusement les horodatages ne fait aucun mal. ;-)

Et au fait, le délai de 35 à 40 secondes que je vois se produit à chaque lancement de mon application simple (pas seulement au lancement de Godot). Cela signifie que Godot est inutilisable dans cet état.

Ah ... vous avez édité votre commentaire. J'utilise un MSI GS75 Stealth 479 . L'exécution avec des graphiques intégrés entraîne les mêmes retards.

J'ai trouvé une solution de contournement:

Au départ, mon ordinateur portable était connecté à un moniteur de jeu incurvé Alienware 1900R 34,1 "via Thunderbolt 3. Si je lance Godot _sans_ le moniteur connecté, tout fonctionne comme prévu.

Ainsi, ma solution de contournement consiste à:

1. Déconnectez mon moniteur
2. Lancer Godot
3. Connecter mon moniteur

Après ces étapes, l'exe Godot se lance sans délai et les lancements suivants de mon exemple de projet fonctionnent également comme prévu.

Comme d'autres l'ont noté, Godot n'utilise aucun processeur pendant le "blocage", donc c'est probablement un seul appel qui est suspendu. Faites-moi savoir s'il existe un moyen de lancer Godot avec une télémétrie / journalisation étendue, car il devrait être assez facile d'isoler le problème. (Encore une fois, j'ai écrit le moteur d'instrumentation d'origine pour le profileur de Visual Studio, je suis donc très familier avec ces types de problèmes).

Au départ, mon ordinateur portable était connecté à un moniteur de jeu incurvé Alienware 1900R 34,1 "via Thunderbolt 3. Si je lance Godot sans le moniteur connecté, tout fonctionne comme prévu.

Le moniteur comprend-il un concentrateur USB? Si tel est le cas, cela pourrait être la raison.

Faites-moi savoir s'il existe un moyen de lancer Godot avec une télémétrie / journalisation étendue, car il devrait être assez facile d'isoler le problème.

Il y a un argument de ligne --verbose commande

Oui, mon moniteur a un concentrateur USB (ce que le moniteur moderne n'a pas?). Et vous avez raison, --verbose n'est pas utile. Je télécharge la source Godot maintenant et je vous ferai savoir si je peux identifier le problème.

Pour moi, c'était un DAC USB (carte son) de la marque FiiO. Le débranchement corrige le lancement lent. Il a même provoqué des lancements lents lorsqu'il était éteint (mode de charge).

Pour les personnes concernées, ce problème ralentit-il également les jeux exportés, ou simplement l'éditeur?

Quelqu'un peut-il essayer de construire Godot à partir des sources et utiliser un débogueur pour comprendre ce qu'il fait lorsque ce ralentissement se produit? Vous devriez généralement pouvoir interrompre l'exécution pendant un ralentissement et voir dans le débogueur quel est le stacktrace actuel.

J'ai eu le même problème, ou au moins les mêmes symptômes. J'ai essayé de débrancher divers périphériques USB, et j'ai trouvé que le coupable était mon Massdrop O2 + ODAC alias "ODAC-revB USB DAC".

Après quelques recherches, je suis tombé sur ce post StackOverflow , qui contenait la solution finale au problème.

Il s'avère que pour une raison quelconque, le DAC ajoute un périphérique supplémentaire aux "Périphériques d'interface humaine" qui apparaît avec le nom générique "Périphérique d'entrée USB". Je n'ai aucune idée de ce qu'il fait, mais sa désactivation dans le gestionnaire de périphériques ne semble pas affecter la fonctionnalité audio (pourquoi un périphérique audio aurait-il même besoin d'un périphérique d'entrée?) Et résout le problème de Godot et de certains jeux (Dark Souls et Sekiro me vient à l'esprit) qui subit de longs gels au démarrage.

Pour identifier le bon "périphérique d'entrée USB" (j'en avais tout un tas, la plupart sans rapport avec le DAC), leur ID de périphérique peut être comparé à celui du périphérique audio réel.
Dans mon cas, le périphérique audio était USB \ VID_262A & PID_1048 & MI_01 \ 7 & 12634547 & 0 & 0001 et le périphérique d'entrée était USB \ VID_262A & PID_1048 & MI_00 \ 7 & 12634547 & 0 & 0000. Notez qu'ils sont identiques, à l'exception du MI_xx et du dernier numéro.

Ajouter à la «chose USB a rendu Godot lent à charger et jouer les voix du projet». J'ai branché mon nouveau clavier Corsair K55 RGB aujourd'hui et chargé Godot. Il a fallu environ 40 secondes pour charger la liste des projets, et 30 autres pour charger le projet: un projet de didacticiel d'une scène avec un script presque vide attaché à un nœud de sprite (oui, j'ai un long chemin à parcourir!). La lecture du projet a pris environ une minute pour que sa fenêtre apparaisse. J'ai arrêté Godot, débranché le clavier et Godot chargé en 3 secondes comme je m'y attendais. Rebranchez le clavier et Godot continue de charger et de jouer des scènes comme d'habitude. Je ne sais pas si j'aurai besoin de débrancher et de rebrancher mon clavier à chaque fois que je veux utiliser Godot. Je vais voir comment ça se passe et mettre à jour ce post.

Edit: J'ai mis à jour le firmware du clavier via le logiciel iCUE de Corsair et cela a résolu le problème. J'arrive à la liste des projets en 2-3 secondes, et dans un projet en environ 3, comme d'habitude ie. avant de brancher un nouveau clavier aujourd'hui.

Je peux confirmer que la mise à jour du micrologiciel de mon clavier corsair K55 via le logiciel ICUE a corrigé le bogue d'énumération lente des périphériques à entrée directe, comme indiqué ici: https://stackoverflow.com/questions/10967795/directinput8-enumdevices-sometimes-painfully-slow

Mon clavier Corsair K70 RGB était sur le firmware v 2.05. Je viens de le mettre à jour à 3.08, ce qui, je suppose, résoudra le problème.

Je veux ajouter que j'ai vu exactement le même problème dans une application complètement différente l'autre jour: le jeu de combat Skullgirls 2nd Encore. Le jeu serait suspendu au lancement et je ne pouvais pas comprendre pourquoi. J'ai essayé de démarrer Godot, et il y avait à nouveau l'ancien problème de chargement, alors j'ai redémarré mon PC (j'aurais probablement dû simplement réinsérer le clavier à la place), et les deux applications étaient bien. Si je vois à nouveau des problèmes après la mise à jour, je reviendrai ici, mais @saulpalv merci pour la réponse, car la modification du commentaire précédent n'a jamais été

IMO, ce problème est plus lié à un mauvais matériel / pilotes / firmware qu'à un bug avec Godot. Compte tenu de la simplicité de la solution de contournement (mettre à jour le micrologiciel de votre périphérique USB ou le réinsérer), je ne suis pas sûr que cela justifie une correction.

IMO, ce problème est plus lié à un mauvais matériel / pilotes / firmware qu'à un bug avec Godot. Compte tenu de la simplicité de la solution de contournement (mettre à jour le micrologiciel de votre périphérique USB ou le réinsérer), je ne suis pas sûr que cela justifie une correction.

Beaucoup de nouveaux joueurs abandonneront le jeu, plutôt que de plonger profondément dans le dépannage de leur système pour découvrir le problème du pilote, en supposant qu'ils aient cette connaissance. L'hypothèse sera que le jeu est bogué et ne peut pas être joué.

S'il y a un moyen de contourner ce problème, cela en vaudrait la peine.

J'ai peut-être manqué le commentaire, mais je pensais que c'était un problème réservé aux rédacteurs. Si cela a également un impact sur les jeux, alors oui, cela devrait probablement être corrigé.

J'ai peut-être manqué le commentaire, mais je pensais que c'était un problème réservé aux rédacteurs. Si cela a également un impact sur les jeux, alors oui, cela devrait probablement être corrigé.

Si ce n'est pas trop compliqué à faire, seriez-vous en mesure de restaurer vos pilotes pour recréer le blocage de l'éditeur et essayer de le recréer sur un projet exporté?

Je n'ai jamais été en mesure de reproduire le problème de manière fiable, même avant de mettre à jour le micrologiciel de mon clavier. Je ne pense pas que le logiciel qui effectue la mise à jour prend en charge la mise à niveau du firmware.

Le mieux que je puisse penser est d'acheter un nouveau clavier (le mien n'est actuellement pas disponible sur Amazon) et j'espère qu'il a un ancien firmware, puis l'utiliser pendant des semaines / mois jusqu'à ce que le bogue se reproduise au hasard.

Cela arrive comme une fois par mois pour moi. Mais tellement ennuyeux, devoir redémarrer l'ordinateur pour le réparer après avoir démarré toutes mes tâches de développement.

Ayant également ce problème, + 30 secondes chacun pour:

• ouvrir la sélection de projets
• projet ouvert
• exécuter la scène.

Je l'ai retrouvé sur mon clavier Corsair K95 RGB. Ma solution de contournement pour le moment consiste à basculer le commutateur de taux d'interrogation / bios sur le clavier lui-même, ce qui fait essentiellement la même chose que la réinsertion du câble USB. Godot fonctionne normalement par la suite.
iCue version 3.27.68. Micrologiciel 3.08v.

Je viens de remarquer que dans iCUE, j'ai également coché "Activer le SDK". Je l'ai également désélectionné pour le moment. Trouvé un lien plus tôt que cela pourrait être la cause.

Godot V3.2.1, mais j'ai eu des problèmes avec les versions antérieures.

@landgrafa Êtes-vous capable de reproduire le problème avec un projet construit?

Le «correctif» USB débranché et rebranché fonctionne pour moi.

La mise à jour du firmware de mon clavier K55 Corsair via iCUE a également fonctionné.

Toujours le meilleur rapport qualité / prix pour la taille / le poids, mais homme, c'était un problème stupide à avoir.

Indice intéressant pour ce bug de Ryan Gordon, car SDL semble souffrir d'un problème similaire: https://mobile.twitter.com/icculus/status/1256845560763551744

Ce pourrait en effet être notre code de sonde de joypad qui provoque le blocage. Nous pourrions peut-être forcer le saut de périphériques qui mettent plus de quelques secondes à répondre et lancer un avertissement afin que les utilisateurs puissent également identifier les périphériques USB nécessitant une mise à niveau du micrologiciel.

Je voudrais aller plus loin et me souvenir de l'appareil sauté (au moins jusqu'à ce que Godot soit relancé) afin que vous puissiez continuer à le sauter au lieu d'attendre 2 secondes et de harceler l'utilisateur à chaque fois. Je dis cela parce que lorsque j'ai eu le problème, il se manifestait à chaque fois que je commençais le débogage.

Ou peut-être déplacer la découverte de périphériques vers un autre thread?

Pour moi, le problème était YETI Microphone on USB lorsque GODOT est branché, il faut 30 secondes pour démarrer, lorsque je le débranche, c'est super rapide.

Le problème pour moi était le casque Razer Kraken USB . Le fait de débrancher le casque m'a fait passer de 20 secondes à 2 secondes.

Si une personne touchée sait comment utiliser un débogueur sous Windows, nous pourrions vraiment utiliser un stacktrace qui montre exactement où le moteur est bloqué pendant cette longue étape d'initialisation:

https://github.com/godotengine/godot/issues/20566#issuecomment -577056589

Compte tenu du problème similaire dans SDL, je suppose que c'est quelque part dans platform/windows/joypad_windows.cpp , mais savoir où exactement aiderait à savoir où abandonner ou mettre sur liste noire les appareils problématiques.

Je me suis obligé à compiler la version 3.2 mais je n'ai pas pu faire fonctionner le débogueur depuis VS.

@sungvzer Je n'ai pas

Vous avez une mise à jour sur le problème, après avoir déplacé le casque vers un concentrateur USB, entre autres appareils, cela a cessé de se produire. Les temps de chargement et de démarrage sont bien plus rapides.

Utilisateur Corsair K70 ici. La mise à jour du firmware l'a corrigé pour de bon.

D'autres éléments USB que j'ai connectés n'étaient pas le problème:
Dongle USB HyperX Cloud, souris Rival 300, carte son Line6 GX, webcam Logitech, ventilateur USB.

Bug intéressant.

On dirait que Corsair est le terrain d'entente notable avec de nombreux cas signalés ici.
J'avais le même problème (Windows 10, alors que sur mon Arch Linux Godot est extrêmement rapide) avec un casque Corsair HS60 et j'ai corrigé le ralentissement en suivant la suggestion principale d'installer le logiciel propriétaire CUE et les pilotes appropriés.
Pour être précis, j'ai installé CUE il y a des mois juste pour avoir les pilotes essentiels, puis désinstallé cette merde de 1,5 Go. Après avoir lu ceci, je viens de réinstaller le logiciel (sans l'exécuter ni mettre à jour les pilotes) et les performances de Godot sont déjà stables.

Mise à jour: j'ai redémarré mon PC et le problème est revenu à nouveau, mais c'est sûr que c'est quelque chose lié au casque.
Si je débranche le câble USB de mon casque (c'est le seul périphérique de sortie audio de mon système), tout va bien à nouveau.
La remise en place du câble USB ne compromettra pas les performances jusqu'au prochain redémarrage du système.

La meilleure solution de contournement que j'ai trouvée est de désinstaller mon casque d'écoute du panneau de commande, de retirer le câble USB et de le réinsérer. Les nouveaux pilotes installés (avec ICUE activé) ne me posent aucun problème.
Serait-ce un conflit entre les anciens pilotes installés sans ICUE, qui peuvent être sélectionnés en premier au lieu des nouveaux mis à jour?

J'ai eu ce problème il y a longtemps et il n'est pas lié à NVIDIA. J'ai eu un problème il y a quelques temps, mes pilotes USB n'étaient pas installés correctement. Godot semble être à la traîne mais tout est toujours réactif. cela se produisait lors du chargement de projets et lorsque j'essayais de lancer le jeu dans l'éditeur Godot.

Godot essaie de vérifier tous les périphériques USB connectés pour voir s'il s'agit d'un clavier, d'un contrôleur de jeu, d'un casque VR, etc. si le contrôleur / pilote USB n'est pas installé correctement, il attendra jusqu'à une minute. Après cette minute, il lancera le jeu de débogage ou chargera des projets.

la réinstallation de vos pilotes résoudra le problème. J'ai trouvé cette information en postant sur godot discord il y a quelques années. J'espère que cela aide. Deux personnes ont même signalé ce problème sur ma diffusion en direct. Mes informations ont aidé beaucoup.

En ce qui concerne les projets de monogame, oui, il se produira tout ce qui vérifie les contrôleurs de jeu ou les périphériques USB. Monogame vérifie également les périphériques USB.

Le problème a été décrit ici (rappel)!

J'ai eu le même problème, ou au moins les mêmes symptômes. J'ai essayé de débrancher divers périphériques USB, et j'ai trouvé que le coupable était mon Massdrop O2 + ODAC alias "ODAC-revB USB DAC".

Après quelques recherches, je suis tombé sur ce post StackOverflow , qui contenait la solution finale au problème.

Il s'avère que pour une raison quelconque, le DAC ajoute un périphérique supplémentaire aux "Périphériques d'interface humaine" qui apparaît avec le nom générique "Périphérique d'entrée USB". Je n'ai aucune idée de ce qu'il fait, mais sa désactivation dans le gestionnaire de périphériques ne semble pas affecter la fonctionnalité audio (pourquoi un périphérique audio aurait-il même besoin d'un périphérique d'entrée?) Et résout le problème de Godot et de certains jeux (Dark Souls et Sekiro me vient à l'esprit) qui subit de longs gels au démarrage.

Pour identifier le bon "périphérique d'entrée USB" (j'en avais tout un tas, la plupart sans rapport avec le DAC), leur ID de périphérique peut être comparé à celui du périphérique audio réel.
Dans mon cas, le périphérique audio était USB \ VID_262A & PID_1048 & MI_01 \ 7 & 12634547 & 0 & 0001 et le périphérique d'entrée était USB \ VID_262A & PID_1048 & MI_00 \ 7 & 12634547 & 0 & 0000. Notez qu'ils sont identiques, à l'exception du MI_xx et du dernier numéro.

Cela a résolu le problème pour moi, j'ai le Topping MX3 qui est une marque différente et j'ai essayé de mettre à jour les pilotes mais Windows dit qu'il est déjà à jour, je me demande si les puces d'entrée USB sont similaires entre elles. Heureux d'avoir trouvé ce correctif car j'ai dû cliquer plusieurs fois sur charger plus de commentaires, je ne sais pas si j'aurais pu souffrir d'attendre 30 secondes pour que le fil débloque chaque itération dans un projet ou sans audio.

Quelqu'un a demandé plus tôt dans le fil, je pense, mais cela se produit également avec une version exportée aussi, je ne sais pas à quelle fréquence ce ralentissement se produirait pendant un jeu fini mais je n'aurais probablement pas essayé de le dépanner avec un jeu fini et je supposez simplement que c'est bogué.

Windows 10 Pro x64
Version 20H2
OS build 19042.572

GPU Nvidia RTX2070 Super
GPU driver 457.09

Confirmer que le problème est toujours présent; Les temps de lancement de l'éditeur et du programme exporté sont normalement inférieurs à la seconde sur mon ordinateur, mais lorsque le problème survient, le lancement peut prendre 30 à 40 secondes. Cela affecte également le débogage dans l'éditeur, qui peut prendre plus d'une minute pour se lancer et se connecter.

Le problème se corrige toujours après un redémarrage, mais reviendra après un certain temps. Je n'ai pas été en mesure d'identifier un déclencheur, mais je soupçonne qu'il pourrait être affecté par l'exécution d'applications en plein écran.

J'ai essayé le correctif USB mentionné ci-dessus, mais je n'ai trouvé aucun appareil qui ait apporté un changement notable.

Confirmer que le problème est toujours présent; éditeur et lancement du programme exporté

Merci pour la confirmation. Cela affecte donc également les versions exportées. C'est inquiétant.