Vscode-vibrancy: Problema al arrastrar, mover la ventana por la barra de título

Gracias por los comentarios y lo siento mucho. No sé cómo arreglar esto. Creo que esto es un error en Windows.

Me he encontrado con este problema también

El efecto acrílico tendrá un retraso de arrastre en la ventana de electrones. Si usa desenfoque detrás o degradado transparente, no aparecerá.

De hecho, nunca he visto tal problema en Windows 10 1809.

Este problema se presenta en Windows 1903 y no se si solo aparece en esta versión. (De hecho, han aparecido algunos errores de interfaz en Windows 1903).

Solo probé esto en Windows 1903. ¿Alguien ha probado esta extensión en versiones más nuevas de Windows Insider? Curiosamente, este problema no parece afectar el uso de GPU o CPU.

Yo también soy 1903 y me enfrento a este problema.

Mismo problema en 1903

El mismo problema

+1

Mismo problema en 1903

Parece ser un problema de 1903 ya que no tengo ningún problema con 1809

+1

En #14 v1.0.6. El retraso del mouse todavía existe, probé muchos métodos y no puedo resolver el problema en 1903.

El problema no está en los electrones, y actualmente no existe una forma perfecta de abrir el efecto acrílico sin UWP en 1903.

El retraso del mouse aún existe en la última vista previa de Windows 10 Insider.

Gracias por tomarse el tiempo para investigar este @EYHN. Me pregunto si hay alguna forma de engañar a Windows para que piense que VSCode/Electron es una aplicación para UWP.

Solo vine aquí para informar este problema. Un poco contento de no ser el único que lo tiene.

En mi PC en el trabajo, especificaciones algo decentes, Windows 1809, se mueve sin demora alguna.
En mi PC de casa, especificaciones mucho mejores, Windows 1903, lento como el infierno.

Han pasado muchos días y este problema sigue ahí.
Empujé el código nativo para Windows en https://github.com/EYHN/vscode-vibrancy/tree/master/src/blur-cli .
Quizas me puedas ayudar si sabes muy bien de windows

noticias: En la ventana 10 1903, descubrí que reducir la "velocidad del mouse" por debajo de la velocidad de fotogramas puede resolver este problema de manera efectiva.

Pasé unos días investigando este problema, y ​​ahora me doy por vencido. Parece ser un problema dentro de DWM, la tasa de sondeo del mouse es más alta que la tasa de pantalla, lo que hace que la solicitud de renderizado se bloquee en la cola y parezca un retraso del mouse.

No se preocupe, el mismo problema también aparece en Microsoft Office, miles de usuarios de Windows están preocupados por él, las siguientes son algunas discusiones:

https://answers.microsoft.com/en-us/msoffice/forum/all/why-my-excel-window-lag-tanto-cuando-se-mueve/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

Ahora hay algunos métodos:

• Use Windows 10 1809 y espere a que Microsoft solucione el problema
• Cerrar 'Mostrar contenido de la ventana al arrastrar'
  En el cuadro de búsqueda de la barra de tareas, escriba "rendimiento", luego seleccione "Ajustar la apariencia y el rendimiento de Windows" en la lista de resultados. En la pestaña 'Efectos visuales', anule la selección de 'Mostrar contenido de la ventana al arrastrar'.

• Reducir la tasa de sondeo del mouse
  En muchos paneles de controladores de mouse para juegos, se puede ajustar la tasa de sondeo del mouse.

  También proporcionaré una versión solo transparente, eliminando el desenfoque y la compatibilidad con todos los sistemas operativos y entornos.

我 的 的 的 的 的 的 的 的 现在 的 的 的 的 现在 我 的 的 的 的 的 的 的 的 的 回报率 的 的 的 的 鼠标 回报率 的 的 的 看起来

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

https://answers.microsoft.com/en-us/msoffice/forum/all/why-my-excel-window-lag-tanto-cuando-se-mueve/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

现在有几种备用方法：

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

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

@EYHN Creo que encontré una solución.
En otra aplicación de electrones Terminus, proporcionan una configuración de "tipo de fondo", y dos tipos "Desenfoque" y "Fluido", llama a una función this.electron.ipcRenderer.send('window-set-vibrancy', enable, type) , y descubrí que "Fluido" funciona con retraso pero "Desenfoque" funciona bien. No sé cómo funciona this.electron.ipcRenderer.send('window-set-vibrancy', enable, type) , pero creo que esta es una solución antes de que MS lo arregle en DWM.

Después de instalar Aero Glass , cambié el código para el procesamiento de win10 para llamar a dwm (es decir, la implementación de win7) y la ventana no se congelaría cuando se arrastrara en win10 1909.

Después de instalar Aero Glass , cuando cambié el código para el procesamiento de win10 para llamar a dwm (es decir, la implementación de win7) parte de la ejecución en win10 1909, la ventana no se congelaba.

Sin embargo Aero Glass no funciona en win10 2004

Después de instalar Aero Glass , cuando cambié el código para el procesamiento de win10 para llamar a dwm (es decir, la implementación de win7) parte de la ejecución en win10 1909, la ventana no se congelaba.

Sin embargo Aero Glass no funciona en win10 2004

¿Tomar el archivo del paquete de depuración del desarrollo general de win10 y luego ordenar la reconstrucción de los símbolos no funcionará?

Otra forma es poner las ventanas en modo de ahorro de energía, que generalmente desactiva todos los efectos de transparencia, pero por alguna razón corrige el retraso 🤷‍♂️

Parece que Win 10 2004 versión KB4541738 soluciona este problema.

¿Puede proporcionar una solución detallada, windows1909 todavía tiene retraso de arrastre?

Extraño, antes corría desempacado con arrastre normal sin demora, pero ahora hay una demora...

Parece que Win 10 2004 versión KB4541738 soluciona este problema.

😂 impresionante

¿Puede proporcionar una solución detallada, windows1909 todavía tiene retraso de arrastre?

¿Puede 1909 usar Aero Glass directamente? pd: el código de extensión necesita ser modificado

Dado que hay un error al arrastrar, ¿se puede resolver proporcionando una imagen de fondo transparente con efecto de vidrio esmerilado?

Use EasyWindowDrag para mover la ventana puede aliviar este problema

Para mí, arrastrar la ventana se volvió imposible con esta extensión instalada. La ventana se mueve a cámara lenta. No es un problema de recursos de CPU/GPU.

Esto hizo que el código VS fuera inutilizable. Tuve que desinstalar esta extensión para usar el código VS nuevamente.

@Spenhouet Gracias por recordarnos qué es este error. Es un problema de Windows que surge como resultado de usar el efecto Acrylic de una manera tan poco compatible, y realmente no hay buenas soluciones.

@ Toby56 No estaba seguro de si es el mismo problema que OP describió. Se ve diferente al GIF que proporcionó.

@Spenhouet Sí, el GIF no es muy claro, ¡pero es como lo describiste! Es un problema de sondeo del mouse, donde tan pronto como comienza a arrastrar, la ventana va más lenta de lo que debería y acumula una demora masiva entre donde está y donde debería estar. Desafortunadamente, no hay nada que puedas hacer al respecto :(

Entonces, ¿sigue siendo un problema a partir de las últimas versiones de Win10? No quiero instalar esto si esencialmente romperá VSCode para mí ...

@iPyGuy Sí, básicamente, no espere que se solucione pronto. No es un método oficial de Windows.

Parece que Win 10 2004 versión KB4541738 soluciona este problema.

Este parche no se fusionó con el oficial de 2004 ni se lanzó al canal semestral.

@EYHN @Toby56
¿Crees que esto se podría "arreglar" desactivando el efecto acrílico mientras se mueve la ventana, como lo describiste (@Toby56) aquí: https://github.com/23phy/ewc/issues/22#issuecomment -599448590?

Alternativamente, ¿cree que sería posible deshabilitar "Mostrar el contenido de la ventana mientras se arrastra" en la configuración de rendimiento solo mientras VSCode está activo/movido, cambiando la entrada de registro relacionada sobre la marcha, en el evento de enfoque o movimiento? No ver el contenido de la ventana para todas las ventanas es bastante malo, pero si eso solo afectara a VSCode, podría vivir con la compensación 😅

@jonaskuske
Deshabilitar el efecto acrílico en el arrastre probablemente sea la mejor solución interna. Puede ser un poco complicado, pero puede cambiarlo a solo transparencia sin desenfoque. Otro factor que lo complica más, es que el acrílico se rompe al habilitarlo desde otro efecto de desenfoque en modo ahorro de batería porque el acrílico suele estar deshabilitado en ese modo? no puedo recordar Debido a esto, debe restablecer el desenfoque cada vez que puede crear un pequeño destello blanco. No hay forma de saber si está en modo de ahorro de batería o no, que yo sepa, y el ahorro de batería no sería muy común. no sé.

Pero funciona en su mayor parte y sería MUCHO MUCHO mejor que jugar con el registro sobre la marcha. Seguro que no creo que hacer eso sea práctico.

@Toby56

el acrílico se rompe al habilitarlo desde otro efecto de desenfoque en modo ahorro de batería porque el acrílico suele estar deshabilitado en ese modo?

Sí, el acrílico generalmente está deshabilitado tanto en el modo de ahorro de energía como cuando una ventana no está enfocada. Por lo tanto, generalmente solo hay una ventana con efectos acrílicos activos, mientras que las del fondo se muestran opacas.

No hay forma de saber si está en modo de ahorro de batería o no, que yo sepa, y el ahorro de batería no sería muy común. no sé.

Para mí, se habilita automáticamente una vez que llego al 20% de la batería, por lo que no diría que es poco común. ¡Pero puedes detectarlo!
Es posible con los enlaces de nodos para la API nativa de Windows Runtime :

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

let energySaverEnabled = PowerManager.energySaverStatus === 2

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

@jonaskuske
¡Es genial que conozca una forma de detectar el modo de ahorro de batería usando enlaces de NodeJS a las funciones nativas de Windows! Parece una forma súper simple de resolver algunos problemas. De esta manera, podemos escribir código que cambia a "borroso detrás" por lo general, y a transparencia simple en el modo de ahorro de batería, eliminando el flash blanco innecesario.

Para este problema específico, no sé cómo está estructurado el código en este proyecto, tendré que preguntarle a @EYHN si quieren implementar algo como esto. Tal vez publique un GIF de él en acción.

@Toby56
Me acabo de dar cuenta de que las dependencias nativas probablemente no sean una opción en las extensiones de VSCode, por lo que si bien esta solución debería ayudar a todos los que quieran agregar el efecto acrílico a su propia aplicación Electron (para que puedan compilarla con su versión específica de Electron/Node), yo no sé si ayuda aquí :/

Probablemente necesitaría enviar un binario preconstruido por separado en lugar de usar los enlaces de Nodo, como ya lo está haciendo este repositorio con blur-cli.exe 🤔

@jonaskuske
¡Eso es cierto! No pensé en eso. No tengo idea de cómo, pero probablemente podría integrarse en la parte de C++ que se compila en el binario. Realmente no conozco las limitaciones de las extensiones de VSCode.

¡Definitivamente útil para mi propia aplicación aunque 😀!

Correcto, eso probablemente debería funcionar. Desafortunadamente, tampoco sé nada sobre C ++ (aparte de lo poco que se necesita para programar Arduinos): /

De todos modos, si esto se implementa, definitivamente debería ser opcional, ya que las personas con, por ejemplo, monitores de 144 Hz pueden tener vitalidad durante el movimiento de la ventana si configuran la frecuencia de muestreo del mouse en algo así como 125, que aún debería ser lo suficientemente rápido para el uso diario.

@quank123wip @EYHN
Sí, yo también lo encontré.
El fondo acrílico en terminal tiene dos opciones:

Blur no tiene ningún problema, y ​​Fluent también tiene un problema de retraso.

Así que creo que esta es la respuesta.

No estoy seguro de si eso es de alguna ayuda, pero la Terminal de ventana tiene un efecto de transparencia funcional. Lo llaman "Acrílico".
La Terminal no se basa en electrones... está implementada en C++.

También puedes cambiar la opacidad:

Tal vez mirar su implementación pueda ayudar:

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

@Spenhouet Sí, lo siento, pero eso realmente no nos ayuda mucho. La Terminal de Windows de código abierto, así como muchas otras aplicaciones, usan este efecto (siempre llamado acrílico), pero son aplicaciones de Windows dedicadas y pueden hacerlo de la manera "oficial", que funcionará de forma inmediata. Sin embargo, lo que estamos haciendo es poner algo donde realmente nunca tuvo la intención de ir, por lo que tiene errores que no se solucionarán.

@Jinhaihan Sí, es cierto, podemos hacer que se desenfoque así, ¡y no tiene ningún problema! Tal vez deberíamos. Pero en mi opinión, no se ve tan bien como el efecto acrílico "fluido". Creo que es un efecto antiguo usado en Windows 7 (Aero), o algo así. El radio de desenfoque no es tanto, y no tiene la textura "acrílica" fluida de Windows 10, así como las otras capas que hacen que el desenfoque acrílico se vea bien.

Tener una opción como Terminus es perfectamente posible, y tal vez una solución con la que muchos estarían contentos.

@ Toby56 Esa podría ser una pregunta tonta: ¿es imposible seguir el camino "oficial"?

@Spenhouet Tal vez, si tiene ganas de reescribir VS Code desde cero. De lo contrario, probablemente no.

En realidad, no sé mucho sobre cómo se aplica el efecto acrílico a una ventana de cromo usando Node JS y C++. Pero VS Code está y siempre estará hecho en Electron, y no hay una forma oficialmente compatible de hacerlo. Estoy bastante sorprendido de que este método funcione. Entonces, a menos que algún genio encuentre otra forma, estamos atrapados así.

@ Toby56 Está bien, tiene sentido.

Supongo que el efecto acrílico estará más presente en Windows en el futuro. El código VS probablemente lo adoptará en un futuro lejano.

@Spenhouet
Sí, actualmente el efecto acrílico es una característica de XAML, el marco de interfaz de usuario que solo pueden usar las aplicaciones modernas de Windows (el tipo que normalmente se ve en Microsoft Store). Es por eso que no es un problema para Windows Terminal y otros. Las aplicaciones de la "vieja escuela" pueden usar la mayoría de las API modernas, pero no aquellas que se basan en renderizado, vistas, etc.
Tampoco sé cómo funciona realmente el truco en este repositorio, pero definitivamente es un truco 😃

Sin embargo, con el próximo WinUI 3 (parte de Project Reunion , el intento de Microsoft de unificar las API antiguas y modernas) obtendremos una característica llamada "Islas XAML", que permite el uso de la interfaz de usuario moderna en aplicaciones tradicionales. Entonces debería ser posible agregar Acrylic sin hacks, tal vez incluso como una característica directa de Electron. 🙏🏻

@jonaskuske Wow, eso es genial, ¡no sabía que Microsoft estaba planeando algo como esto! Algunas cosas, como los íconos de la bandeja, no son posibles para las aplicaciones UWP sin empaquetar una aplicación Win32 complementaria.

Me complace informar que Windows 10 Insider Preview (compilación 20161) me solucionó el problema.

@LegoLivesMatter ¡Es fantástico escuchar eso! Debería pasar al canal de información privilegiada rápida para verificar esto.

@ Toby56 ¡Buena suerte!

@jonaskuske @LegoLivesMatter @racoonx2p @EYHN

¡Puedo confirmar que está arreglado en la compilación 20161!
Bueno sobre todo ...

Digo principalmente porque, si bien es genial y completamente utilizable ahora, es un poco peculiar. Cambiar el tamaño todavía tiene este problema para mí, lo cual es molesto, pero probablemente no sea un problema para nadie, a menos que te encuentres cambiando mucho el tamaño. Los cambios de tamaño cortos y rápidos están bien.

Chico, se ve bien aunque:

Tengo monitores duales, y el mismo problema también. Además, si la ventana está cerca de un borde de cualquiera de los monitores, una pequeña parte de ese borde se vuelve translúcido sin desenfoque. Aún mejor que nada!

También noté que cuando la ventana de VS Code está maximizada en el monitor secundario, el desenfoque desaparece pero el "filtro" acrílico permanece allí. Por lo que puedo decir, esto es una consecuencia de que la ventana "alcanza" ligeramente el otro monitor. Esto no sucede cuando la ventana de VS Code no está enfocada o cuando está maximizada en el monitor principal.

@LegoLivesMatter Sí, también tuve este problema, olvidé mencionarlo. Tan estúpido, pero las ventanas a menudo llegan al siguiente monitor, y esta es obviamente la causa. Crucemos los dedos y tal vez se arregle. ¡Esperemos que tanto el efecto rompa como el cruce de ventana!

Por alguna razón, usar un tema con Stardock WindowBlinds también resuelve este problema. Debe estar haciendo algo con la composición del administrador de ventanas, pero no tengo idea de qué. Hay un parpadeo rápido al maximizar la ventana, pero por lo demás es bueno.

Instalé Windows-Insider Dev-Channel, y el arrastre está bien. Sin embargo, cambiar el tamaño todavía plantea problemas. También he notado que mi aplicación winforms de 64 bits que usa este método tiene este problema, pero no la versión de 32 bits. Además, tengo una aplicación de prueba de WPF que es de 32 y 64 bits mientras uso SetWindowCompositionAttribute y cambia de tamaño correctamente. Además, Avalonia cambia de tamaño OK.

Use EasyWindowDrag (estilo KDE).ahk puede aliviar este problema

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

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

Gracias por su respuesta, pero dije que no tuve problemas para arrastrar (es decir, mover la ventana) en el canal de desarrollo interno, pero tuve problemas para cambiar el tamaño en la aplicación de 64 bits.

Esto parece haberse solucionado en la versión de Windows que estoy usando ahora.
Descubrí esto de repente, así que no estoy seguro si es esta versión.

@doublethinkio Estoy en Windows 10 compilación 19042.541 y todavía tengo el problema.

20H2 compilación 19042.572 aquí y también todavía sucede, así que creo que algo que @doublethinkio ha hecho específicamente ha hecho que funcione correctamente. Para mí, arrastrar funciona y es suave, es muy, muy lento. Eso es diferente de algunas personas en las que es lento y no suave.

@Jinhaihan mencionó que Blur funciona para ellos en Terminus y Fluent tiene el mismo problema en este comentario . Me gustaron 5 minutos de investigación y parece que "Blur" se asigna a la opción 3, llamada ACCENT_ENABLE_BLURBEHIND en el blur-cli de este proyecto y "Fluent" se asigna a la opción 4, llamada ACCENT_ENABLE_ACRYLIC en blur-cli . Esto no es configurable, y en su lugar siempre se elige ACCENT_ENABLE_ACRYLIC (en realidad llamado ACCENT_ENABLE_ACRYLICBLURBEHIND en la API).

Hacer esto configurable sería bastante trivial, pero no tengo una cadena de herramientas de Visual C++ configurada para poder construir un nuevo blur-cli.

Cómo eliminar el efecto de vidrio esmerilado, desinstalo el complemento y elimino la configuración.todavía inútil

@doublethinkio , gracias por proporcionar una solución. Intenté ejecutar EasyWindowDrag.ahk con autohotkey.exe . Desafortunadamente, recibo el siguiente error. No tengo problemas para ejecutar otros scripts de AutoHotkey.

Incluso si uso el script original que descargué directamente de:
https://lexikos.github.io/v2/docs/scripts/EasyWindowDrag.ahk

Use EasyWindowDrag (estilo KDE).ahk puede aliviar este problema

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

No estoy seguro de si esto ayuda, pero aquí hay un proyecto que parece que podría ayudar con el problema.
Seo-Rii/ventana-acrílica-de-electrones

Descubrí que al configurar el fondo de Terminus ( eugeny/terminus 1.0.127) en Fluent, establecerá el fondo como no transparente al arrastrar la ventana. Después de detenerse o permanecer temporalmente, la ventana restaura el fondo fluido. El retraso no aparecerá.

Tal vez esta sea una buena solución para el proyecto.

La última versión (v1.0.10) contiene una solución para el retraso del mouse, consulte aquí para obtener más detalles .

EDITAR: Acabo de probar la solución. ¡Definitivamente es más rápido, incluso en 60 hz! ¡¡¡Gracias!!!