Vscode-vibrancy: Problème de glisser, déplacer la fenêtre par la barre de titre

Merci pour vos commentaires et vraiment désolé. Je ne sais pas comment résoudre ce problème. Je pense que c'est un bug de Windows.

j'ai aussi rencontré ce problème

L'effet acrylique aura un retard de traînée sur la fenêtre Electron. Si vous utilisez un flou derrière ou un dégradé transparent, il n'apparaîtra pas.

En fait, je n'ai jamais vu un tel problème dans Windows 10 1809.

Ce problème se produit dans Windows 1903 et je ne sais pas s'il n'apparaît que dans cette version. (En fait, certaines erreurs d'interface sont apparues dans Windows 1903.)

Je n'ai essayé cela que sur Windows 1903. Quelqu'un a-t-il essayé cette extension sur les nouvelles versions Insider de Windows ? Fait intéressant, ce problème ne semble pas affecter l'utilisation du GPU ou du CPU.

Je suis aussi en 1903 et je suis confronté à ce problème

Même problème sur 1903

Même problème

+1

Même problème sur 1903

Semble être un problème de 1903 car je n'ai aucun problème sur 1809

+1

Dans #14 v1.0.6. Le décalage de la souris existe toujours, j'ai essayé de nombreuses méthodes, et je n'arrive pas à résoudre le problème en 1903.

Le problème n'est pas dans l'électron, et il n'existe actuellement aucun moyen parfait d'ouvrir l'effet acrylique sans UWP en 1903.

Le décalage de la souris existe toujours dans le dernier aperçu d'initié de Windows 10.

Merci d'avoir pris le temps d'examiner ce @EYHN. Je me demande s'il existe un moyen de tromper Windows en lui faisant croire que VSCode/Electron est une application UWP.

Je viens ici pour signaler ce problème. Un peu content de ne pas être le seul à l'avoir.

Sur mon ordinateur au travail, des spécifications quelque peu décentes, Windows 1809 - se déplace sans aucun décalage.
Sur mon PC à la maison, de bien meilleures spécifications, Windows 1903, lent comme l'enfer.

Plusieurs jours ont passé et ce problème est toujours là.
J'ai poussé le code natif pour Windows à https://github.com/EYHN/vscode-vibrancy/tree/master/src/blur-cli .
Peut-être que vous pouvez m'aider si vous connaissez très bien les fenêtres

news : Dans la fenêtre 10 1903, j'ai trouvé que réduire le "taux de la souris" en dessous de la fréquence d'images peut résoudre efficacement ce problème.

J'ai passé quelques jours à faire des recherches sur ce problème, et maintenant j'abandonne. Cela semble être un problème dans DWM, le taux d'interrogation de la souris est supérieur au taux d'écran, provoquant le blocage de la demande de rendu dans la file d'attente, et cela ressemble à un retard de la souris.

Ne vous inquiétez pas, le même problème apparaît également dans Microsoft Office, des milliers d'utilisateurs de Windows en sont troublés, voici quelques discussions :

https://answers.microsoft.com/en-us/msoffice/forum/all/why-does-my-excel-window-lag-so-much-when-moved/04b1fb97-b9da-481e-b37a-63257460c5b7

https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-mouse-lag-sluggish-window-dragging-in/12ab88a5-9e13-4d37-8f2d-106d56fcd775

Il existe maintenant des méthodes :

• Utilisez Windows 10 1809 et attendez que Microsoft résolve le problème
• Fermer 'Afficher le contenu de la fenêtre tout en faisant glisser'
  Dans le champ de recherche de la barre des tâches, tapez "performances", puis sélectionnez "Ajuster l'apparence et les performances de Windows" dans la liste des résultats. Dans l'onglet "Effets visuels", décochez "Afficher le contenu de la fenêtre lors du glissement".

• Réduire le taux d'interrogation de la souris
  Dans de nombreux panneaux de pilote de souris de jeu, vous pouvez ajuster le taux d'interrogation de la souris.

  Je fournirai également une version transparente uniquement, supprimant le flou et la compatibilité avec tous les systèmes d'exploitation et environnements.

花 了 好 我 我 放弃 放弃 的 的 样 看来 就 像 延迟 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 样 一样.

不要担心，同样的问题还出现在Office软件中，上千Windows用户受到其困扰，以下是一些讨论：

https://answers.microsoft.com/en-us/msoffice/forum/all/why-does-my-excel-window-lag-so-much-when-moved/04b1fb97-b9da-481e-b37a-63257460c5b7

https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-mouse-lag-sluggish-window-dragging-in/12ab88a5-9e13-4d37-8f2d-106d56fcd775

现在有几种备用方法：

• Pour Windows 10 1809，然后等待微软修复问题
• 关闭 "拖动时显示窗口内容"
  在任务栏搜索性能，选择 « 调整 Windows 外观和性能 », 在 « 视觉效果 » 选项卡关闭 « 拖动时显示窗口内容 »
• 降低鼠标回报率一般游戏鼠标驱动面板都可以调整鼠标回报率

之后我还会提供一个仅透明版本，去掉模糊效果并兼容所有操作系统和桌面环境。

@EYHN Je pense avoir trouvé une solution.
Dans une autre application électronique Terminus, ils fournissent un paramètre "type d'arrière-plan", et deux types "Flou" et "Fluent", il appelle une fonction this.electron.ipcRenderer.send('window-set-vibrancy', enable, type) , et j'ai trouvé que "Fluent" fonctionne en retard mais "Flou" fonctionne bien. Je ne sais pas comment fonctionne this.electron.ipcRenderer.send('window-set-vibrancy', enable, type) , mais je pense que c'est une solution avant que MS ne le corrige dans DWM.

Après avoir installé Aero Glass , j'ai changé le code pour le traitement win10 pour appeler dwm (c'est-à-dire l'implémentation win7) et la fenêtre ne se figeait pas lorsqu'elle était glissée dans win10 1909.

Après avoir installé Aero Glass , lorsque j'ai modifié le code du traitement win10 pour appeler dwm (c'est-à-dire l'implémentation win7) dans le cadre de l'exécution sur win10 1909, la fenêtre ne gèle pas.

Cependant Aero Glass ne fonctionne pas dans win10 2004

Après avoir installé Aero Glass , lorsque j'ai modifié le code du traitement win10 pour appeler dwm (c'est-à-dire l'implémentation win7) dans le cadre de l'exécution sur win10 1909, la fenêtre ne gèle pas.

Cependant Aero Glass ne fonctionne pas dans win10 2004

Prendre le fichier du package de débogage du développement général de win10, puis ordonner de reconstruire les symboles ne fonctionnera pas ?

Une autre façon consiste à mettre les fenêtres en mode d'économie d'énergie, ce qui désactive généralement tous les effets de transparence, mais pour une raison quelconque, cela corrige le décalage 🤷‍♂️

Il semble que Win 10 2004 version KB4541738 corrige ce problème.

Pouvez-vous fournir une solution détaillée, Windows1909 a toujours un délai de traînée

Étrange, j'avais l'habitude de courir décompressé avec une traînée normale sans délai, mais maintenant il y a un délai...

Il semble que Win 10 2004 version KB4541738 corrige ce problème.

😂génial

Pouvez-vous fournir une solution détaillée, Windows1909 a toujours un délai de traînée

1909 peut-il utiliser Aero Glass directement ? ps : le code d'extension doit être modifié

Puisqu'il y a un bogue dans le glissement, peut-il être résolu en fournissant une image d'arrière-plan transparente avec un effet de verre dépoli à la place ?

Utiliser EasyWindowDrag pour déplacer la fenêtre peut résoudre ce problème

Pour moi, faire glisser la fenêtre est devenu impossible avec cette extension installée. La fenêtre se déplace au ralenti. Ce n'est pas un problème de ressource CPU/GPU.

Cela rendait le code VS inutilisable. J'ai dû désinstaller cette extension pour utiliser à nouveau le code VS.

@Spenhouet Merci de nous rappeler ce qu'est ce bug. C'est un problème Windows qui résulte de l'utilisation de l'effet acrylique d'une manière si peu prise en charge, et il n'y a pas vraiment de bonnes solutions.

@ Toby56 Je ne savais pas s'il s'agissait du même problème que celui décrit par OP. Il semble différent du GIF qu'il a fourni.

@Spenhouet Ouais, le GIF n'est pas très clair, mais c'est comme tu l'as décrit ! C'est un problème d'interrogation de la souris, où dès que vous commencez à faire glisser, la fenêtre va plus lentement qu'elle ne le devrait et accumule un retard considérable entre l'endroit où elle se trouve et l'endroit où elle devrait être. Malheureusement, vous ne pouvez rien y faire :(

Est-ce donc toujours un problème avec les dernières versions de Win10 ? Je ne veux pas l'installer si cela va essentiellement casser VSCode pour moi ...

@iPyGuy Ouais, en gros, ne vous attendez pas à ce qu'il soit corrigé de si tôt. Ce n'est pas une méthode officielle de Windows.

Il semble que Win 10 2004 version KB4541738 corrige ce problème.

Ce patch n'a pas été fusionné avec le patch officiel de 2004 ni publié sur le canal semi-annuel.

@EYHN @Toby56
Pensez-vous que cela pourrait être "réparé" en désactivant l'effet acrylique pendant le déplacement de la fenêtre, comme vous (@Toby56) l'avez décrit ici : https://github.com/23phy/ewc/issues/22#issuecomment -599448590 ?

Alternativement, pensez-vous qu'il serait possible de désactiver "Afficher le contenu de la fenêtre lors du glissement" dans les paramètres de performances uniquement lorsque VSCode est actif/déplacé, en modifiant l'entrée de registre associée à la volée, lors de la mise au point ou de l'événement de déplacement ? Ne pas voir le contenu de la fenêtre pour toutes les fenêtres est assez mauvais, mais si cela n'affectait que VSCode, je pourrais vivre avec le compromis 😅

@jonaskuske
La désactivation de l'effet acrylique sur la traînée est probablement la meilleure solution interne. Cela peut être fastidieux, mais vous pouvez le changer en transparence sans aucun flou. Un autre facteur qui complique les choses est que l'acrylique se casse lorsqu'il est activé à partir d'un autre effet de flou en mode économiseur de batterie, car l'acrylique est généralement désactivé dans ce mode ? Je ne m'en souviens pas. Pour cette raison, vous devez réinitialiser le flou à chaque fois, ce qui peut créer un petit flash blanc. Il n'y a aucun moyen de savoir s'il est en mode économiseur de batterie ou non, pour autant que je sache, et l'économie de batterie ne serait pas très courante. je ne sais pas.

Mais cela fonctionne pour la plupart et serait BEAUCOUP BEAUCOUP mieux que de jouer avec le registre à la volée. Bien sûr, je ne pense pas que cela soit pratique.

@Toby56

l'acrylique se casse lorsqu'il est activé à partir d'un autre effet de flou en mode économiseur de batterie car l'acrylique est généralement désactivé dans ce mode ?

Oui, l'acrylique est généralement désactivé à la fois en mode économie d'énergie et lorsqu'une fenêtre n'est pas focalisée. Il n'y a donc généralement qu'une seule fenêtre avec des effets acryliques actifs, tandis que ceux en arrière-plan s'affichent opaques.

Il n'y a aucun moyen de savoir s'il est en mode économiseur de batterie ou non, pour autant que je sache, et l'économie de batterie ne serait pas très courante. je ne sais pas.

Pour moi, il est automatiquement activé une fois que j'ai atteint 20% de batterie, donc je ne dirais pas que c'est rare. Mais vous pouvez le détecter !
C'est possible avec les liaisons de nœuds pour l'API Windows Runtime native :

const { PowerManager } = require('@nodert-win10/windows.system.power')

let energySaverEnabled = PowerManager.energySaverStatus === 2

PowerManager.on('energySaverStatusChanged', () => {
  energySaverEnabled = PowerManager.energySaverStatus === 2
})

@jonaskuske
C'est formidable que vous connaissiez un moyen de détecter le mode d'économie de batterie à l'aide des liaisons NodeJS aux fonctions Windows natives ! Cela ressemble à un moyen super simple de résoudre certains problèmes. De cette façon, nous pouvons écrire du code qui passe généralement au "flou derrière" et à la transparence pure en mode économiseur de batterie, éliminant ainsi le flash blanc inutile.

Pour ce problème spécifique, je ne sais pas comment le code de ce projet est structuré, je devrai demander à @EYHN s'ils veulent implémenter quelque chose comme ça. Je posterai peut-être un GIF de celui-ci en action.

@Toby56
Je viens de réaliser que les dépendances natives ne sont probablement pas une option dans les extensions VSCode, alors que cette solution devrait aider tous ceux qui souhaitent ajouter l'effet acrylique à leur propre application Electron (afin qu'ils puissent le compiler avec leur version Electron/Node spécifique), je je ne sais pas si ça aide ici :/

Aurait probablement besoin d'expédier un binaire pré-construit séparé au lieu d'utiliser les liaisons Node, comme ce référentiel le fait déjà avec blur-cli.exe 🤔

@jonaskuske
C'est vrai! Je n'y ai pas pensé. Je n'ai aucune idée de comment, mais cela pourrait probablement être intégré à la partie C++ qui est compilée dans le binaire ??? Je ne connais vraiment pas les limites des extensions VSCode.

Certainement utile pour ma propre application 😀 !

D'accord, cela devrait probablement fonctionner. Malheureusement je n'y connais rien en C++ non plus (à part le peu qu'il faut pour programmer des Arduinos) :/

Quoi qu'il en soit, si cela est implémenté, cela devrait certainement être facultatif, car les gens avec par exemple des moniteurs 144Hz peuvent avoir du dynamisme pendant le mouvement de la fenêtre s'ils règlent leur taux d'échantillonnage de la souris sur quelque chose comme 125, ce qui devrait toujours être assez rapide pour un usage quotidien.

@quank123wip @EYHN
Oui, je l'ai trouvé aussi.
Le fond acrylique au terminus a deux options :

Le flou n'a pas de problème, et Fluent a aussi un problème de décalage.

Je pense donc que c'est la réponse.

Je ne sais pas si cela est utile, mais le terminal Windows a un effet de transparence fonctionnel. Ils l'appellent "Acrylique".
Le terminal ne s'appuie pas sur l'électron... il est implémenté en C++.

Vous pouvez également modifier l'opacité :

Peut-être que regarder leur mise en œuvre peut aider:

https://github.com/microsoft/terminal/blob/master/src/cascadia/TerminalControl/TermControl.cpp#L376

@Spenhouet Ouais, désolé mais ça ne nous aide pas vraiment beaucoup. Le terminal Windows open source ainsi que de nombreuses autres applications utilisent cet effet (toujours appelé acrylique), mais ce sont des applications Windows dédiées et peuvent faire de la manière "officielle", qui fonctionnera prête à l'emploi. Cependant, ce que nous faisons, c'est mettre quelque chose là où il n'a jamais été prévu d'aller, c'est pourquoi il y a des bogues qui ne seront pas corrigés

@Jinhaihan Oui, c'est vrai, nous pouvons simplement le rendre flou comme ça, et ça n'a pas de problème! Peut-être que nous devrions. Mais à mon avis, il n'est pas aussi beau que l'effet acrylique "fluide". Je pense que c'est un ancien effet utilisé dans Windows 7 (Aero), ou quelque chose comme ça. Le rayon de flou n'est pas aussi important et il n'a pas la texture "acrylique" fluide de Windows 10, ainsi que les autres couches qui contribuent à rendre le flou acrylique agréable.

Avoir une option comme Terminus est parfaitement possible, et peut-être une solution dont beaucoup seraient satisfaits.

@ Toby56 C'est peut-être une question stupide : est-il impossible de suivre la voie "officielle" ?

@Spenhouet Peut-être, si vous avez envie de réécrire VS Code à partir de zéro. Sinon, probablement pas.

En fait, je ne sais pas grand-chose sur la façon dont l'effet acrylique est appliqué à une fenêtre en chrome à l'aide de Node JS et C++. Mais VS Code est et sera toujours créé dans Electron, et il n'y a aucun moyen officiellement pris en charge de le faire. Je suis assez étonné que cette méthode fonctionne du tout. Donc, à moins qu'un génie ne trouve un autre moyen, nous sommes coincés comme ça.

@ Toby56 D'accord, c'est logique.

Je suppose que l'effet acrylique sera plus présent dans Windows à l'avenir. Le code VS adoptera probablement cela dans ce futur lointain.

@Spenhouet
Oui, actuellement l'effet acrylique est une fonctionnalité de XAML, le framework d'interface utilisateur que seules les applications Windows modernes (le type que vous voyez généralement dans le Microsoft Store) peuvent utiliser. C'est pourquoi ce n'est pas un problème pour Windows Terminal et les autres. Les applications "à l'ancienne" peuvent utiliser la plupart des API modernes, mais pas celles qui reposent sur le rendu, les vues, etc.
Je ne sais pas non plus comment le hack de ce dépôt fonctionne réellement, mais c'est définitivement un hack 😃

Cependant, avec le prochain WinUI 3 (qui fait partie de Project Reunion , la tentative de Microsoft d'unifier les API anciennes et modernes), nous aurons une fonctionnalité appelée "Îles XAML", qui permet l'utilisation de l'interface utilisateur moderne dans les applications traditionnelles. Ensuite, il devrait être possible d'ajouter de l'acrylique sans hacks, peut-être même en tant que caractéristique directe d'Electron lui-même. 🙏🏻

@jonaskuske Wow c'est plutôt cool, je ne savais pas que Microsoft prévoyait quelque chose comme ça !!! Certaines choses comme les icônes de la barre d'état ne sont pas possibles pour les applications UWP sans empaqueter une application Win32 associée.

Je suis heureux d'annoncer que Windows 10 Insider Preview (build 20161) a résolu le problème pour moi.

@LegoLivesMatter C'est fantastique à entendre ! Je devrais passer au canal d'initié rapide pour vérifier cela.

@Toby56 Bonne chance !

@jonaskuske @LegoLivesMatter @racoonx2p @EYHN

Je peux confirmer que c'est corrigé dans la build 20161 !
Ben surtout ...

Je dis surtout parce que, même si c'est génial et complètement utilisable maintenant, c'est un peu bizarre. Le redimensionnement a toujours ce problème pour moi, ce qui est ennuyeux, mais probablement pas un problème pour personne, à moins que vous ne redimensionniez beaucoup. Les redimensionnements courts et rapides conviennent.

Garçon, est-ce que ça a l'air bien:

J'ai deux moniteurs et le même problème aussi. De plus, si la fenêtre est proche d'un bord de l'un des moniteurs, une petite partie de ce bord devient translucide sans flou. C'est toujours mieux que rien !

J'ai également remarqué que lorsque la fenêtre VS Code est maximisée sur le moniteur secondaire, le flou disparaît mais le "filtre" acrylique reste là. D'après ce que je peux dire, c'est une conséquence du fait que la fenêtre "atteint" légèrement l'autre moniteur. Cela ne se produit pas lorsque la fenêtre VS Code n'est pas focalisée ou lorsqu'elle est maximisée sur le moniteur principal.

@LegoLivesMatter Oui, j'ai eu ce problème aussi, j'ai oublié de le mentionner. Si stupide, mais les fenêtres atteignent souvent le moniteur suivant, et c'est évidemment la cause. Croisons les doigts et peut-être que ça s'arrangera. Espérons à la fois l'effet brisant et le franchissement de fenêtre !

Pour une raison quelconque, l'utilisation d'un thème avec Stardock WindowBlinds résout également ce problème. Il doit faire quelque chose avec la composition du gestionnaire de fenêtres, mais aucune idée de quoi. Il y a un scintillement rapide lors de la maximisation de la fenêtre mais sinon c'est bon.

J'ai installé dev-channel windows-insider, et le glissement est correct. Cependant, le redimensionnement pose toujours des problèmes. J'ai également remarqué que mon application winforms 64 bits utilisant cette méthode a ce problème, mais pas la version 32 bits. De plus, j'ai une application de test WPF de 32 et 64 bits lors de l'utilisation SetWindowCompositionAttribute , et elle se redimensionne correctement. De plus, Avalonia se redimensionne correctement.

Utilisez EasyWindowDrag (style KDE).ahk peut atténuer ce problème

https://www.autohotkey.com/
https://lexikos.github.io/v2/docs/scripts/~~

https://autohotkey.com/board/topic/22565-updated-easywindowdrag-kdeahk-with-added-control-support/

Merci pour votre réponse, mais j'ai déclaré que je n'avais pas de problèmes avec le glissement (c'est-à-dire le déplacement de la fenêtre) sur le canal insider-dev, mais que j'avais des problèmes de redimensionnement sur l'application 64 bits.

Cela semble avoir été corrigé sur la version de Windows que j'utilise actuellement.
J'ai découvert cela tout d'un coup, donc je ne sais pas si c'est cette version.

@doublethinkio Je suis sur Windows 10 build 19042.541 et j'ai toujours le problème ?

20H2 build 19042.572 ici et cela se produit toujours, donc je pense que quelque chose que @doublethinkio a spécifiquement fait fonctionner correctement. Pour moi, faire glisser fonctionne et est fluide, c'est juste très très lent. C'est différent de certaines personnes où c'est à la fois lent et pas fluide.

@Jinhaihan a mentionné que Blur fonctionne pour eux dans Terminus et Fluent a le même problème dans ce commentaire . J'ai fait 5 minutes de recherche et il semble que "Blur" correspond à l'option 3, appelée ACCENT_ENABLE_BLURBEHIND dans les cartes $#$1 blur-cli #$ de ce projet et "Fluent" à l'option 4, appelée ACCENT_ENABLE_ACRYLIC en blur-cli . Ce n'est pas configurable, et à la place ACCENT_ENABLE_ACRYLIC (en fait appelé ACCENT_ENABLE_ACRYLICBLURBEHIND dans l'API) est toujours choisi.

Rendre cela configurable serait assez trivial, mais je n'ai pas de chaîne d'outils Visual C++ configurée pour pouvoir créer un nouveau blur-cli.

Comment supprimer l'effet de verre dépoli, je désinstalle le plugin et supprime la configuration.toujours inutile

@doublethinkio , merci d'avoir fourni une solution de contournement. J'ai essayé d'exécuter EasyWindowDrag.ahk avec autohotkey.exe . Malheureusement, j'obtiens l'erreur ci-dessous. Je n'ai aucun problème à exécuter d'autres scripts AutoHotkey.

Même si j'utilise le script original que j'ai téléchargé directement depuis :
https://lexikos.github.io/v2/docs/scripts/EasyWindowDrag.ahk

Utilisez EasyWindowDrag (style KDE).ahk peut atténuer ce problème

https://www.autohotkey.com/
https://lexikos.github.io/v2/docs/scripts/

; Easy Window Dragging -- KDE style (based on the v1 script by Jonny) 
; https://www.autohotkey.com
; This script makes it much easier to move or resize a window: 1) Hold down
; the ALT key and LEFT-click anywhere inside a window to drag it to a new
; location; 2) Hold down ALT and RIGHT-click-drag anywhere inside a window
; to easily resize it; 3) Press ALT twice, but before releasing it the second

Je ne sais pas vraiment si cela aide, mais voici un projet qui pourrait aider à résoudre le problème.
Seo-Rii/électron-acrylique-fenêtre

J'ai trouvé que définir l'arrière-plan de Terminus ( eugeny/terminus 1.0.127) dans Fluent, il définira l'arrière-plan comme non transparent lors du déplacement de la fenêtre. Après un arrêt ou un séjour temporaire, la fenêtre restaure un arrière-plan fluide. Le décalage n'apparaîtra pas.

C'est peut-être une bonne solution de contournement pour le projet.

La dernière version (v1.0.10) contient une solution au décalage de la souris, veuillez voir ici pour plus de détails .

EDIT : je viens d'essayer le correctif. C'est définitivement plus rapide, même sur 60hz ! Merci!!!