Pour moi ce que tu décris ressemble a un problème de cache. Problème de permission ? Désactivé ? Je n'utilise pas Windows mais il faut chercher dans ce sens.
J'allais répondre à pascal que ce n'était pas un problème spécifique Windows puisque les délais annoncés par pim sont exactement ceux que j'avais observés sous Linux Mint 20 il y a quelques jours.
Mais je viens de refaire un test à l'instant et cette fois ça réagit quasi-immédiatement... alors que je n'ai rien changé dans ma config et que je n'ai pas lancé la commande darktable-generate-cache.
C'est tant mieux mais franchement, je ne me l'explique pas
Si le cache n'est pas généré, darktable va le faire. Ca n'est pas nouveau. De base, darktable 3.2 est fait pour être plus rapide. Maintenant la 1ère génération du cache prend quelques secondes (ça dépend du traitement appliqué et de la.config du PC). Pzr contre, ensuite c'est immédiat. J'ai une petite config, sans OpenCL, qui a plus de 6 ans. C'est plus rapide qu'en version 3.0.x.
Je penche donc aussi pour un problème de génération de cache lié à un problème de permissions. Ou peut-être à un problème sur Windows (on a peu de testeurs Windows).
(21-08-20, 11:15)pascal a écrit : [ -> ]Pour moi ce que tu décris ressemble a un problème de cache. Problème de permission ? Désactivé ? Je n'utilise pas Windows mais il faut chercher dans ce sens.
J'ai exploré cette piste aujourd'hui.
J'ai finalement réussi à afficher les sous dossiers censés héberger le répertoire des caches; (c'est un peu plus compliqué que de cocher "afficher les dossiers cachés" dans les options de l'explorateur)
Surprise, le répertoire mipmaps se trouve dupliqué dans les 2 sous dossiers "INetCache\Darktable" et "Temporary Internet Files\Darktable"
Tous les niveaux de cache sont dupliqués à l'identique dans les 2 arborescences.
Est ce la cause du problème ?
Sauf si un "expert windows" a une nouvelle piste, je pense que je suis au bout de mes compétences et je ne vais pas enqui... la communauté DT avec un problème qui ne concerne (?) que moi. Je me passerai des aperçus en affichant 1 ou 2 miniatures dans la TL et en passant de suite dans la chambre noire pour zoomer si besoin de controler la netteté.
Merci à tous
Bonjour à tous
ce message est à destination des utilisateurs Windows qui rencontreraient le même problème.
J'ai trouvé la solution au problème de délai d'affichage des miniatures plein écran: mes raw Sony A7R3 s’ouvrent maintenant instantanément.
Mon écran est de définition 3840 x 2160; de ce fait j'avais compris que dans les paramètres il fallait retenir comme facteur d'échelle DPI des miniatures la valeur de 2;
comme la réactivité de l'affichage était trop lente ( 15 sec), j'étais revenu à la valeur de -1, avec le même résultat;
après avoir testé tous les autres paramètres des préférences, sans résultat, j'ai essayé la valeur de +1, et là miracle...! affichage instantané.
problème réglé.
(21-09-20, 17:06)Pim a écrit : [ -> ]Bonjour à tous
ce message est à destination des utilisateurs Windows qui rencontreraient le même problème.
J'ai trouvé la solution au problème de délai d'affichage des miniatures plein écran: mes raw Sony A7R3 s’ouvrent maintenant instantanément.
Mon écran est de définition 3840 x 2160; de ce fait j'avais compris que dans les paramètres il fallait retenir comme facteur d'échelle DPI des miniatures la valeur de 2;
comme la réactivité de l'affichage était trop lente ( 15 sec), j'étais revenu à la valeur de -1, avec le même résultat;
après avoir testé tous les autres paramètres des préférences, sans résultat, j'ai essayé la valeur de +1, et là miracle...! affichage instantané.
problème réglé.
Merci de ton partage. Si tu peux éditer le message initial de ce fil et ajouter [résolu] au titre, ce serait parfait. Ca aiderait encore plus des utilisateurs rencontrant le même problème à trouver ta solution.