No vi esto en mi VM, asigne a @Tyriar para verificar si él también lo ve en su linux para que evaluemos qué tan serio es

No tengo mi computadora portátil Linux conmigo en este momento, lo marcaré este octubre para recordármelo. / cc @alexandrudima

Tengo esto, aunque no está presente en todas partes. El panel de vista de árbol y todos los editores ya no se desplazan suavemente, pero las entradas que (supongo) probablemente están usando la representación del navegador, como las páginas de detalles de extensiones, aún se desplazan suavemente.

corriendo:
arch linux - x86_64 Linux 4.7.6-1-ARCH
GNOME Shell 3.22.1

No puedo decir nada diferente en la vista de árbol o en el editor que compara 1.6.0 y 1.5.3 usando Ubuntu 16.04. @bpasero @alexandrudima alguna idea?

Duplicado de https://github.com/Microsoft/vscode/issues/12637

No creo que esto sea un duplicado de ese problema, ese problema indica que no funciona en absoluto, mientras que este problema está puramente relacionado con el desplazamiento suave: el desplazamiento con 2 dedos funciona, pero actúa como un desplazamiento regular 'saltado'.

Estoy de acuerdo con @ jshap70 , este es un problema diferente al que describió.

Creo que esta es una regresión en Chromium (también lo noté allí) que se solucionó para mí en 54.

Puedo confirmar esto, usar el desplazamiento con dos dedos para el editor es lento. Usando la versión 1.6.1 en mi máquina con Windows 10.

AFAIK, no tuvimos cambios en la lógica de manejo de desplazamiento, pero actualizamos a una versión electrónica más nueva (que incluye Chromium 52).

Sería interesante saber si Chrome 52 también sufre este problema. Tenemos exactamente el mismo código de desplazamiento en el editor https://microsoft.github.io/monaco-editor/, así que si alguien quisiera probarlo e informar aquí los hallazgos, estaría agradecido.

Hay muchos problemas con los paneles táctiles en Chromium: https://bugs.chromium.org/p/chromium/issues/list?can=2&q=touchpad

¿Estamos ante un problema conocido para ellos?

El desplazamiento en Mónaco es suave y se siente igual que vscode antes para mí dentro de Chrome (beta) 55.0.2883.21 y Chromium 54.0.2840.71.
Acabo de construir una versión de Chromium 52.0.2743.85 para probar, y puedo confirmar que tiene el mismo desplazamiento saltado. Usar Mónaco dentro de él es especialmente difícil. Esto confirma la idea de que probablemente sea un error de electrones y no un error de vscode. gorrón.

@ jshap70 Muchas gracias por confirmar que se trata de un error de Chromium que se solucionará una vez que obtengamos una versión más nueva. fyi @bpasero

También he experimentado esto hoy en mi Surface Book. Es un verdadero fastidio. Lo más extraño es que después de usar un mouse por un tiempo, el trackpad estaba funcionando normalmente nuevamente. Lamento que no haya nada que pueda hacer de nuestro lado, tenemos eventos de rueda del ratón y los respetamos cuando los tenemos.

Electron aún no adoptó Chrome 54, pero está en su plan.

@ jshap70, ¿la solución se incluye en Chrome 53 o 54?

@bpasero Acabo de

Estuve jugando con este por un tiempo. Prueba con un Lenovo Yoga 910 (Kaby Lake) - Windows 10 Pro.

Durante mis pruebas, descubrí que el retraso se produce si inicia VS Code maximizado. Pensé que tal vez me estaba volviendo loco, pero todo lo que hice fue restaurar la ventana y luego volver a maximizarla y todo el desplazamiento de desplazamiento desapareció.

Solo para asegurarme de que no estaba perdiendo mis canicas, hice que mi esposa lo probara a ciegas. Era una diferencia de día y de noche. Espero que esto ayude a identificar el problema, me sumergiré para intentarlo esta noche o mañana.

Tengo el mismo problema de desplazamiento en Lenovo Yoga 910.
Después de cambiar el tamaño, el desplazamiento de la ventana es suave nuevamente.

Tengo una Surface 4 Pro y tengo el mismo problema. Cambiar el tamaño de la ventana corrige el desplazamiento.

Probablemente debería mencionar que el problema que he estado rastreando a través del cromo solo está presente en mi Thinkpad Lenovo W530 en Linux, no en Windows, y no se resuelve cambiando el tamaño de la ventana. Ese podría ser un tema completamente diferente.
¿Alguien que tiene esos problemas puede intentar instalar una versión de chrome o chromium 52 o 53 y verificar si Mónaco tiene el mismo problema?

Tengo este problema en mi SurfacePro4. El uso del panel táctil hace que el editor se retrase al desplazarse si la ventana es de tamaño completo. Si cambio el tamaño de la ventana para poder ver un poco mi escritorio, el problema desaparece.

El mismo problema me ocurre al usar Win 10 y un nuevo Surface Book. Puedo confirmar que cambiar el tamaño de la ventana y remaximizar parece resolverlo (al menos hasta ahora).

Actualmente estoy usando la última versión con mi Dell XPS 15 9550 (versión de pantalla táctil, Win10 x64) y estoy experimentando este problema exacto. Ni siquiera sabía que no ocurre cuando uso el desplazamiento de la pantalla táctil, solo con el panel táctil.

El truco de redimensionar / maximizar lo corrige al menos un poco.

Mismo problema que aquí. Surface Book / Windows 10, pero resuelve al máximo. Sería genial no tener que hacerlo cada vez que abro VS Code.

Dado que Chromium 54 se ha integrado en Electron , ¿tal vez VSCode pueda cambiar al nuevo Electron para resolver definitivamente el problema?

Todavía no hay un lanzamiento de Electron con Chrome 54 fuera.

Se supone que la liberación de electrones con Chrome 54 ocurrirá en enero

De electron / pull / 8406

(...) Vamos a lanzar esto como una versión beta 1.5.0 a npm ahora

¿Hay alguna forma de ser notificado cuando los Insiders se actualizarán al nuevo Electron?

Yo también estoy esperando el nuevo Electron. Tener una pantalla y un editor tan hermosos plagados de un desplazamiento terrible es una lástima.

Este problema también existe en Dell XPS 13 9360 QHD de finales de 2016. Observó que solo el panel táctil (controladores de Windows Precision) se ve afectado mientras el desplazamiento con la pantalla táctil funciona bien.

Esto todavía parece ser un problema en 1.10.2 (Dell XPS 15, la pantalla táctil es suave)

Entonces, ¿cuál es el problema ahora? Se indicó que esto debería haberse solucionado en enero.

Me gustaría reiterar mi comentario anterior de que este problema específico no está realmente rastreando el problema en Windows, ya que la información que publiqué sobre el desplazamiento roto en cromo estaba relacionada con Linux.
Dicho esto, el problema sigue presente en la versión actual de vscode

Podemos desarrollar un desplazamiento suave personalizado como en atom y también se relaciona con https://github.com/Microsoft/vscode/issues/21359

@pixieaka actualmente, el código usa el desplazamiento nativo de Chrome, que en mi opinión personal es mucho mejor que cualquier cosa que se construya sobre él cuando funciona correctamente. Además, el desplazamiento es fijo y funciona correctamente cuando se realiza en Mónaco en versiones más actuales de Chrome (ver aquí ), por lo que se sabe que es un problema de electrones. Así que no hay una necesidad real de reescribirlo ya que no es un problema de código.

Solo necesitan esperar a que el electrón se actualice a Chromium 54, que creo que se puede rastrear aquí

@ jshap70 Electron v1.6.2 ya se lanzó con Chromium (56.0.2924.87) hace 16 días

@ jshap70 https://github.com/Microsoft/vscode/issues/11953 Esta es una compilación con la última versión de Electron 1.6.2 con Chromium (56.0.2924.87) para Windows aquí: https://az764295.vo.msecnd.net/insider /d42d4467e681308a5f82b61cb11ee6b91f1b9864/VSCode-win32-1.11.0-insider.zip

Pero el problema con scroll aún no está resuelto.

@pixieaka ¿ qué problema con el desplazamiento? este problema es para desplazarse en Linux, no en Windows

@ jshap70 https://github.com/Microsoft/vscode/issues/20840 Tengo el mismo problema con la computadora portátil Dell en Windows 10. El desplazamiento es muy nervioso con el track-pad.

@pixieaka podría estar relacionado con el desplazamiento de retraso en Windows. Tengo el mismo problema aquí. https://github.com/Microsoft/vscode/issues/20348#issuecomment -291060102

Esto me está volviendo loco, tengo que restaurar / maximizar cada minuto mientras trabajo. ¿Alguna actualización sobre esto?

La compilación interna de VS Code de hoy viene con Electron 1.6.x, sería interesante saber si esta actualización resuelve este problema para alguien: http://code.visualstudio.com/Download#insiders

@bpasero No creo que ese enlace funcione, ¿debería ser https://code.visualstudio.com/insiders en su lugar?
Lo comprobaré cuando tenga la oportunidad y te lo haré saber.

@bpasero ¡Me complace decir que el desplazamiento suave está de vuelta en la nueva versión de información privilegiada! en Linux, eso es.

¡Genial, gracias!

En mi Dell XPS 13 SkyLake, Precision TouchPad, Windows 10 @ 125% de escala, todavía presenta el mismo problema para la compilación interna actual a5e9d3

Más información:

Parece que la pantalla solo se actualiza al final de la sesión. Entonces, desplazamiento con 2 dedos ... (parece que no pasó nada / congelado)
luego levante los dedos <- actualizaciones de pantalla.

Perdón por el doble comentario, pero encontré que usar "--disable-gpu" hace que el desplazamiento sea súper suave nuevamente para mí.

Gracias a https://github.com/Microsoft/vscode/issues/14716#issuecomment -293120446 por la sugerencia.

¿Hay alguna forma de hacer que esta bandera esté siempre encendida, incluso cuando se lanza código desde el menú contextual?
Editar: parece que no

Tener una forma de ejecutar Código con parámetros específicos sería una buena idea (¿qué pasa con startup.json en ~ que se usaría para los parámetros de la línea de comandos?), Pero prefiero que se solucione el problema relacionado con gpu.

¿Qué hay de malo en crear un script de shell global que ejecute code --disable-gpu ?

No hay nada de malo en tener un atajo global. Pero deshabilitar la gpu para solucionar un error no es muy bueno si me preguntas. Usar la GPU en lugar de la CPU para renderizar / desplazarse puede tener un gran impacto en la batería, el rendimiento, etc.

Probado en xps, ¡parece muy prometedor! En una instalación limpia, la primera impresión es bastante suave. Necesitará ver cómo es con todos los complementos, pero ahora hay esperanza.

Puede confirmar, Dell XPS 15 9560 + Windows 10 Creators Update, --disable-gpu funciona como una solución alternativa.

aún no es suave en la superficie del libro, incluso ejecuta --disable-gpu

Confirmo que no es fluido en Surface Book (actualización de los creadores): ya no salta tanto, pero es bastante lento.

¿Alguien en el equipo central de Code tiene ese dispositivo o todos trabajan en Mac? :)

@warpdesign Estoy en un Surface Book. Mi solución es "restaurar" y "maximizar" la ventana del Código VS una vez después de abrirla. El desplazamiento de dos dedos en el trackpad se vuelve suave para mí.

Comencé una página wiki para recopilar / resumir la información informada sobre este problema: https://github.com/Microsoft/vscode/wiki/Known-issues

Desactivar gpu no funciona en xps 15 ", minimizar / maximizar funciona pero solo por un momento, tengo que seguir haciéndolo. Sigue siendo el mismo problema en la última versión.

@vladkosarev me funciona, ¿ha intentado actualizar al último controlador de gráficos Intel desde su sitio web?

No estoy seguro de si se ha mencionado, pero este es un problema de Electron. A mí me pasa lo mismo en el cliente de escritorio de Slack.

También tengo el problema en una computadora portátil ASUS Zenbook. Desmaximizar (y volver a maximizar) parece solucionar el problema temporalmente.

• Versión de VSCode: Código 1.12.1 (f6868fce3eeb16663840eb82123369dec6077a9b, 2017-05-04T21: 26: 50.689Z)
• Versión del sistema operativo: Windows_NT ia32 10.0.14393
• Extensiones:

| Extensión | Autor | Versión |
| --- | --- | --- |
| EditorConfig | EditorConfig | 0.9.3 |
| CppSnippets | hars | 0.0.9 |
| tabsanity | jedmao | 0.0.9 |
| contextualduplicate | lafe | 0.2.0 |
| cpptools | ms-vscode | 0.11.0 |
| espacios finales | shardulm94 | 0.2.11 |
| vscode-fileutils | sleistner | 2.5.1 |
| ninja | surajbarkale | 0.0.1 |;

Tengo el mismo problema en mi Dell XPS 9560. Encontré una solución extraña

Haga clic derecho en la barra de tareas y seleccione la configuración de la barra de tareas
Cambie la orientación de la barra de tareas a lo opuesto a lo que sea en este momento, es decir, si es inferior, establezca en Superior o viceversa. Si es izquierda, derecha, etc.
Cambie la barra de tareas de nuevo a la orientación original o déjela como está, no importa.
Desplazamiento suave de nuevo
Tengo que hacer esto cada vez que inicio VS Code, pero funciona.

También experimentando el problema. El truco de minimizar / maximizar ayuda, pero seguro que es molesto. Desafortunadamente, no hay información reciente sobre el problema en el repositorio de Electron .

Computadora portátil: Dell XPS 9560
Sistema operativo: Win 10 Pro 10.0.15063
Código VS: 1.12.2

El mismo problema aquí con un Acer Nitro 15.

Computadora portátil: Acer V Nitro 15
SO: Win 10 Pro
Código VS: 1.14.0-insider

El mismo problema aquí en Acer. Restaurar / La ventana de código máximo y el desplazamiento con dos dedos funcionan nuevamente.

Computadora portátil: Acer Aspire F5-573
SO: Win 10 Home 1703
Código VS: 1.13.0

Se actualizó el código VS a la compilación 1.14.0 de información privilegiada y el problema persiste.

Se puede resolver restaurando / maximizando la ventana o ejecutando código con --disable-gpu.

El mismo problema en Surface pro 4. (I5, 8GB, 256G).
SO: Win 10 Home 1703
Código VS: 1.13.0
Se puede resolver cambiando el tamaño de la ventana.

No estoy seguro de si ayudará o no, pero encontré este artículo ridículamente detallado sobre el desplazamiento :) https://pavelfatin.com/scrolling-with-pleasure/

El mismo problema aquí.
SO: Win 10 pro compilación 14393
Código VS: 1.13.1

Creo que está relacionado con el sistema operativo. Las aplicaciones integradas en Win 10 no admiten el desplazamiento de TrackPoint tan bien, el código puede usar algunas bibliotecas dentro del sistema operativo.

solución temporal rápida: Win + DOWN, Win + UP

Estoy en información privilegiada, Surface Book (modelo i5 de 8 gb), el desplazamiento es extremadamente lento.

¿Qué tal si alguien del equipo de VSCode obtiene acceso a un Surface Book (o cualquier panel táctil de precisión) y definitivamente ve lo que está mal y se le da una solución adecuada (o solución)?

Los dispositivos Surface son las máquinas insignia de Microsoft para Windows 10: me enoja que el rendimiento de VSCode sea tan malo en una máquina tan hermosa (además de evitar que haga un trabajo serio con VSCode).

@warpdesign Algunos miembros del equipo de VSCode tienen dispositivos Surface y son conscientes del problema ( ver upthread ). Si bien es muy irritante, es un problema aguas arriba que nadie ha podido resolver todavía.

Sin embargo, no estoy muy seguro de que alguien esté trabajando en eso ... Creo que Electron solo está diciendo que es un problema de Chrome, pero no pude encontrar un error en el rastreador de problemas, excepto este, que básicamente no tiene ninguna actividad. pasando .. ¿Alguien sabe si alguien está trabajando en esto?

También me está sucediendo en mi 4k XPS 9550 y me está volviendo loco. Amo tanto VS Code, pero tener que minimizarlo / maximizarlo cada 5 minutos es tan molesto ...

https://bugs.chromium.org/p/chromium/issues/detail?id=713907

@tobiasviehweger No es de extrañar que todavía esté allí :(

¿Se puede reproducir el problema en Chrome con Monaco? ¿O es específico de VSCode + Electron?

Desplazamiento entrecortado y básicamente inútil en Dell XPS13 / Windows 10 hasta que probé el truco --disable-gpu. No es ideal. ¿Alguna señal de que Electron se esté moviendo a un cromo más reciente?

+1 sufriendo el problema aquí.
De hecho, compré Surface Book debido a su excelente panel táctil y teclado, y principalmente para trabajar, por lo que es un problema crítico para mí, estoy considerando devolver Surface Book y comprar mac nuevamente :(
Mi versión de VSCode:

Otro dato:
En mi antiguo Mac Air 11 "(con Win 10 instalado, no macosx), el panel táctil funciona muy bien en VSCode.
Versión:

¿Arreglar por favor?

Algunos detalles más.

Lo que sucede exactamente en mi Surface Book es que cuando deslizo hacia arriba o hacia abajo con dos dedos:

• la mayor parte del tiempo, se desplaza, pero after a 1 second lag
• a veces no sucede nada en absoluto, como si el evento no llegara a VSCode
• algunas veces, el desplazamiento se realizará justo a tiempo

Como puede ver, esto es muy poco confiable y hace que VSCode sea inutilizable en tales dispositivos.

Quería ver qué sucedía con los eventos DOM, pero en el segundo que abrí las herramientas de desarrollo, el desplazamiento comenzó a funcionar como se esperaba, es decir, sin el retraso de 1 segundo y en cada deslizamiento. Esto hace que sea difícil ayudar a rastrear el problema.

@kokajambo @ Deiru2k ¿ Es eso lo que tú también estás experimentando?

Descubrí que: mostrar u ocultar el menú principal funciona igual que cambiar el tamaño de la ventana. Entonces, si normalmente tiene el menú oculto, una rápida pulsación de 2 toques en la tecla alt cuando el desplazamiento se vuelve inestable hará que sea suave nuevamente por un tiempo.

¿Electrón alguna vez se actualizó?

Sí, actualizamos Electron varias veces desde que se informó por primera vez de este problema. En el momento en que se informó el problema, estábamos usando una versión de Electron construida en Chromium 52. Ahora estamos en Chromium 56, mientras que el navegador Chrome está en Chromium 60.

Los problemas aguas arriba:
Electron: https://github.com/electron/electron/issues/8960 (cerrado a favor del problema de Chromium)
Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=713907 (el propietario del problema de Chromium no pudo reproducir con Chromium 58)

Si queremos ser optimistas, una vez que actualicemos a una versión de Electron construida en Chromium> = 58, este problema debería solucionarse.

Si el problema no se soluciona, tendríamos que pedir más ayuda a nuestros amigos de Electron, ya que podría ser una indicación de que se trata de un problema específico de Electron.

Mientras tanto, la solución sigue funcionando (cambie el tamaño de la ventana una vez después de haberla abierto).

Yo también tengo este problema.
Versión de VSCode: Código 1.14.2 (cb82feb, 2017-07-19T23: 34: 09.706Z)
Versión del sistema operativo: Windows_NT ia32 10.0.15063

usando código --disable-gpu resolvió el problema

Puedo confirmar este problema en mi razer stealth, que minimizar / maximizar lo soluciona durante algún tiempo.

@ IanNS333 Lo mismo aquí, con Dell XPS 13 (9350).

Esto parece peor después de la reciente actualización.

Solía ​​estar entrecortado, pero desaparecería si cambiaba el tamaño de la ventana y la maximizaba de nuevo, como han dicho otros. Ahora simplemente no se desplaza en absoluto. La ventana en sí parece "rebotar" ligeramente cuando dos buscadores se desplazan.

Uso de una computadora portátil Samsung 9

Me encontré con este problema en un ASUS UX501JW e investigué un poco.

Descripción del problema: El desplazamiento funciona en cada versión cuando ejecuto Chrome o Electron normalmente, si corro como administrador, ninguna de las versiones probadas funciona.

Versiones probadas:
- Chrome 62 (navegador independiente, canario)
- Chrome 60 (navegador independiente)
- Cromo 58 (Electron 1.7.5)
- Cromo 56 (Electron 1.6.6)
- Chrome 54 (navegador independiente)
- Chrome 51 (navegador independiente)

SO: Windows 10

Este error no está ni en VS-code ni en Electron, sino en Chrome o en cómo se escriben las utilidades táctiles. Solo quería agregar información sobre mis hallazgos de que para las computadoras portátiles ASUS no hay luz en el túnel.

Hablando de computadoras portátiles ASUS (UX360CAK aquí) y Windows 10, el desplazamiento en todo el sistema ha sido muy problemático para mí durante el último mes. Por ejemplo, cuando me desplazo hacia abajo por una página (Chrome) o una lista de elementos (Thunderbird, pero no el Explorador de archivos), la posición de desplazamiento se restablecerá al principio de la lista al azar.

Otra cosa es que tuve que desactivar el zoom de pellizco porque la cantidad de detecciones falsas era insoportable, pero nunca antes había tenido problemas con esto. Volver a un trackpad de Macbook Pro fue como una especie de revelación religiosa.

(Editar: eliminé mi publicación sobre la desinstalación de la utilidad asus y la reversión del controlador nativo del panel táctil de Windows, ya que ninguno de estos parece haber resuelto los problemas con la peculiaridad y posiblemente (tbd) vscode)

@youurayy Sí, Dell XPS 13 y encantado de haber descubierto cómo desactivar el pellizco para hacer zoom, ya que me estaba volviendo loco.

@youurayy Descubrí una solución para que el desplazamiento no funcione cuando se ejecuta Chrome / Electron como administrador en computadoras portátiles ASUS.

Solución alterna:

• Elimine las aplicaciones ASUS Smart Gesture en el administrador de tareas,
• Reinicie las aplicaciones Smart Gesture con ejecutar como administrador (AsusTPCenter.exe, AsusTPHelper.exe, AsusTPLoader.exe)

Una suposición informada es que este problema tiene sus raíces en dos cosas:

• ASUS Smart Gestures probablemente esté enviando sus eventos táctiles de alguna manera extraña a otras ventanas, he visto discusiones de que no sigue el estándar de touchpad de Microsoft
• Chrome bloquea los eventos de los procesos que no se ejecutan en un nivel elevado si Chrome se ejecuta en un nivel elevado

No hay un método para deshacerse de Smart Gesture y todavía tener scroll en un modelo ASUS nuevo, pero esto me da algo con lo que puedo trabajar.

Wow, esto fue publicado en octubre de 2016? Realmente espero que esto se solucione antes. Publiqué un nuevo número # 35844 que fue un engaño y cerré. Descubrí que al deshabilitar Todos los complementos, era mejor, pero no del todo suave. Pero esa tampoco es una solución óptima. El retraso para mí es de casi 1/2 segundo en un i7 Surface Book. Probé la opción code --disable-gpu y tampoco es del todo suave, pero es mejor, por lo que es una solución por debajo del par.

Conectar un mouse demostró ser una solución al 100%. Lo cual es un poco irónico.

@ Deiru2k Sí, el desplazamiento de la rueda del mouse está bien, pero un mouse no se desplaza exactamente igual que un panel táctil. El panel táctil tiene cierta velocidad; todos lo sabemos por nuestros dispositivos de pantalla táctil. Cuanto más rápido se deslice, más rápido debería desplazarse. La rueda del mouse se desplaza por X filas y es más un desplazamiento por pasos.

Esto todavía me está sucediendo en mi Dell XPS15 con el VSCode más reciente (actualizado hoy). Mi solución es hacer clic en ganar + flecha hacia abajo y ganar + flecha hacia arriba. Esto cambia la ventana de VS Code para que no se maximice y luego vuelva a maximizarse. Eso funciona, pero es realmente molesto.

por cierto, otra pieza de información. Si pruebo el desplazamiento suave con dos dedos en Visual Code 1.17.0 en mi escritorio que tiene un panel táctil Logitech, parece que funciona bien. ¿Quizás esto sea algo relacionado con controladores específicos del panel táctil? En Surface Book, es desigual y no responde. Pero Chrome y Edge son completamente suaves. Tal vez no esté completamente relacionado con la aplicación, tal vez con los controladores, ¿o tal vez sea la tasa a la que Electron muestrea? Realmente no lo sé.

Tengo este problema en Surface Pro 4, vscode 1.17.0.
maximizar / minimizar ayuda temporalmente como lo mencionaron otros.

El problema es específico de ciertos dispositivos. Mi máquina personal (una computadora portátil asus rog) se comporta exactamente como esperaría que se comportara el desplazamiento con dos dedos, mientras que mi máquina de trabajo (una computadora portátil de precisión dell) tiene el problema reportado aquí.

Además, para reiterar lo que otros miembros del equipo de vscode ya han dicho, esto parece ser un problema con electron (que puedo confirmar, ya que puedo reproducir el problema en otras aplicaciones de electron), y lo más probable es que el equipo de vscode no pueda solucionarlo. , Desafortunadamente.

Según este hilo de emisión de electrones , el problema está en el propio Chrome.

Esto es lo que encontré en el rastreador de errores de Chrome: (enlace)

@EthanRutherford ¿Ha probado la solución alternativa para ASUS mencionada en https://github.com/Microsoft/vscode/issues/13612#issuecomment -324351903?

Reiniciar AsusTPLoader.exe como administrador resuelve el problema de las computadoras portátiles ASUS en las que hemos probado. Incluso construimos un módulo de nodo en nuestra aplicación Electron que hace esto automáticamente, ya que no podemos esperar que nuestros usuarios finales realicen ese trabajo.

@EthanRutherford No estoy seguro de que este sea el mismo problema que electron / # 8960 en el informe de error de Chrome

Además, no experimenté el problema en Chrome.

De hecho, experimenté algo similar con Chrome en algún momento. Y en ese momento el truco de minimizar-restaurar también ayudó. Quizás Chrome también use Electron.

@mogemimi En realidad, es al revés: Electron está basado en Chrome.

También tengo este problema en Dell XPS 13.

@robinwassen la computadora portátil asus es en realidad la que se está comportando correctamente. El trackpad de Dell es el que tiene el problema. Sin embargo, normalmente trabajo con un mouse USB, por lo que no experimento este problema con frecuencia.

@dopare mencionó que cambiar el tamaño de Visual Code corrige el problema. El esta en lo correcto. Es probable que el problema esté relacionado con el contenedor (electrón).

Por cierto, tengo el mismo problema para Chrome.
Se encontró un problema posiblemente relacionado https://bugs.chromium.org/p/chromium/issues/detail?id=765311

con el dell xps tengo el mismo problema, el cambio de tamaño ayuda por un tiempo, y no tengo este problema con Chrome, solo vscode.

El mismo problema en Schenker XMG P507 (Win 10, CPU / GPU: i7-7700HQ, Touchpad: Synaptics SMBus). Peor aún para hacer que el desplazamiento con el panel táctil sea inutilizable. No hay problemas en Google Chrome.

mismo problema en el libro de superficie con base de rendimiento, mi sistema está debajo

No tengo problema con el ultimo Chrome

version 1.17.1
shell 1.7.7
chrome 58.0.3029.110
node 7.9.0
arch ia32

@saedrna También tengo un desplazamiento lento en Surface Book, pero solo cuando uso la pantalla interna de alta resolución. ¿Conectar un monitor externo (uno normal, no 4K) acelera el desplazamiento?

Un archivo .mustache de 40 (sí, cuarenta) líneas hace que el desplazamiento de vscode sea un desastre, así que sospeche que esto también está en electron.

Habiendo pasado de 1.17.2 a 1.18.0, el rendimiento de desplazamiento interno ahora es fijo.

¿Alguien más quiere probar la versión de información privilegiada actual e informar sus resultados?

Lo probé en mi Surface Book (la última versión preliminar de Visual Code) y es mucho mejor. No es un pergamino mantecoso como cabría esperar, pero es mucho mejor que antes.

Todavía roto para mí - Versión de VSCode: Código - Insiders 1.18.0-insider (e6a76e4bd3f52ab07452bb181e861f5a9bfb6596, 2017-10-27T04: 19: 22.491Z)

(Panel táctil de precisión Dell XPS 13)

1. Menú Inicio de Windows -> Code Insiders
2. Code Insiders se abre maximizado a mi proyecto anterior
3. Desplazamiento aún inutilizable (no se mueve durante el desplazamiento, luego de repente hace un salto masivo después de un tiempo)

¡Buenas noticias!

Esto ha sido recogido por el equipo de Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=779372

Excelente. El código Vs no está nada mal, pero este problema me volvió loco hasta el punto de que dejé de usarlo por completo.

@CoenraadS que mencionaste antes:

Si VSCode comienza en blanco y luego abro una carpeta, funciona bien.

Podría valer la pena presentarlo como un problema separado del rendimiento de desplazamiento general, ya que probablemente tenga una causa diferente.

Había estado usando VSC en Windows 10 y Ubuntu 17.10 (creo que Gnome 3.26) y estaba funcionando perfectamente, ahora estoy viendo este problema en Fedora 27 también con Gnome 3.26.2.
Estoy ejecutando VSCode 1.19
También está sucediendo en otras aplicaciones de Electron, como Atom.
Cambiar el tamaño de la ventana no me sirve: [

Entonces, ¿todos aquí solo tienen problemas en VS? Tengo una Dell Inspiron 7577 Gaming y este problema de desplazamiento afecta a casi todo. Eclipse y Chrome lo tienen peor. También está en Discord, Slack, editor de texto Atom y árbol de fuentes. Me está volviendo tan loco que estoy a punto de devolver este portátil.

@ RJ-Fynydd También tengo el mismo problema en Sublime, en un HP Spectre x360. Si mal no recuerdo, lo tenía en Chrome pero lo "arreglé" desactivando el desplazamiento suave en chrome: // flags /.

Esto estaba sucediendo bastante mal en mi Surface Book y era muy notable. Algo en las dos últimas versiones lo ha mejorado (estoy en 1.18), sin embargo, todavía noto que se pone un poco nervioso después de su uso. En uso, quiero decir, abrir un archivo de código grande, desplazarse, trabajar en el archivo, guardar, cambiar a otros archivos y volver. Un cambio de tamaño de la ventana parece corregirlo, por lo que todavía hay algo extraño con el tiempo de los ciclos de exploración de toque / desplazamiento.

Todavía no es suave en mi libro de superficie, no puedo creer que lo aguante durante casi un año

@ivyhaswell , ¿tienes la última versión de código visual? ¿Qué sucede cuando cambia el tamaño del IDE? ¿Se va?

Si está usando Gnome, puede solucionar esto usando Xorg en lugar de Wayland.
Puede cambiarlo antes de iniciar sesión.
La vida vuelve a ser genial.

@alanosman versión 1.8.1, el desplazamiento será normal durante varios minutos después del cambio de tamaño.

@ivyhaswell está bien, eso confirma que tenemos el mismo problema en Surface Book. Con suerte, alguien aquí más hábil que yo se ocupará de este problema. :-)

Esto parece estar sucediendo también en Macbook Pro (2015, Retina). Solía ​​funcionar muy bien, ahora con un proyecto muy pequeño abierto, Chrome, Slack y algunos otros (la CPU no supera el 1-3%, la RAM se usa 9.4 / 16GB), se retrasa cuando se desplaza.

El problema aún persiste. Tengo una Dell XPS 13 2017, win10. Afortunadamente, se corrigió el cambio de tamaño de la ventana, como algunos de ustedes señalaron aquí. Gracias

Vengo aquí buscando una solución a este problema.
Y veo que el problema ha estado en curso durante más de un año ...
Estoy usando un Asus Strix ROG GL753.

Hu, pensé que sería mi error, pero es bueno ver que existe un workaorund (ventana de cambio de tamaño). Estoy usando el trackpad de precisión de Asus.

Tener el mismo problema (Lenovo Ideapad 720s / 8th gen i7 / 8 gb ram / nvidia geforce mx150)

Lo mismo aquí, desplazamiento muy inestable con mi panel táctil con controladores de precisión de Windows. A veces funciona, a veces no. Versión del código VS: 1.18.1 x64

Obteniendo el mismo problema al desplazarme en mi Surface Pro (2017)

Este problema todavía existe en las noches. Estoy usando un Surface Book i7 de primera generación. No estoy seguro de si esto es una coincidencia de tiempo, pero solo comencé a notar este problema después de actualizar a Fall Creators Update.

Creo que este problema se está convirtiendo lentamente en una característica 😄

Resuelto en chormium hace 11 horas: https://chromium-review.googlesource.com/c/chromium/src/+/809829#message -85e8d8e27337bf85caecffcd4978f979a67f1378.
Todavía están monitoreando, ya que el código con errores agregado tenía que ver con los hilos de la gpu.
El error del electrón relacionado con este problema: https://github.com/electron/electron/issues/8960

Espero que el parche aparezca pronto en vscode :)

Mismo problema con mi skylake XPS13

Mismo problema. Espero que se solucione pronto

Parece que Chrome está probando una solución para este problema (a través de https://bugs.chromium.org/p/chromium/issues/detail?id=713907#c28) y produje una compilación de información privilegiada de VS Code con ese parche actualizado. Hice algunas pruebas en mi Surface Book donde parece que el problema desapareció.

Si la gente pudiera intentarlo e informar: Descargue VS Code Insiders 64bit

@bpasero parece estar funcionando.

@bpasero Corregido aquí también para XPS 13

@bpasero Trabajando muy bien aquí. Usando Asus ROG Strix. ¡Gracias!

@bpasero ¡Impresionante! ¡Gracias!

@bpasero ¿Significa esto que podríamos aplicar la corrección en las compilaciones

@warpdesign podemos tenerlo antes en nuestras compilaciones internas porque creamos Electron para VS Code con nuestros propios cambios personalizados si es necesario.

Muchísimas gracias

Oye, estoy usando una computadora portátil ASUS R500VD, con Windows 8.1 x64 Pro.

Cuando inicio VSCode desde git-bash usando code . , no puedo usar el toque con dos dedos o el desplazamiento con dos dedos en mi panel táctil. Pero funciona, si inicio VSCode directamente desde el menú de inicio.

23062 se cerró como un duplicado, pero parece bastante distinto y aún no ha sido resuelto por nada aquí.

A menos que esto aún no esté en versión estable, el desplazamiento todavía es muy importante para mí.
Surface book i5 8gb.

@bpasero, ¿ podría confirmar si la solución está en las compilaciones internas actuales o no? Estoy usando la información privilegiada más reciente, en un Surface Book, y obtengo un rendimiento de desplazamiento deficiente:

Version 1.20.0-insider
Commit 8697a5e4ec152832a2612929c87d56302dbb2e79
Date 2018-01-03T05:14:21.686Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

La solución alternativa mencionada en # 40319 se aplica aquí. Cambiar el tamaño de la ventana lo vuelve rápido.

La solución NO está en estable y NO en información privilegiada.

Gracias @bpasero. Por favor, avísenos cuando sea así, instalé la compilación de prueba anterior, pero se borró cuando salió una actualización (que pensé que tenía la solución).

Hola
También sufre este problema en VSC 1.19.1 en un flamante Dell XPS 15 9560 nuevo. También es un fastidio.

Cambiar el tamaño del panel funciona bien, pero es demasiado irritante para las palabras. Descargué la compilación 1.20 pero no pude abrir ningún archivo (.ps1, .py, .rb, .go todo se bloquea).

¡Realmente espero que esta solución sea estable y GA pronto! La razón principal por la que compré esta máquina fue para tener una experiencia VSC más rica.

Gracias por todos sus esfuerzos.

Con la última versión estándar para Windows 10 y Dell XPS 13, todavía tengo que usar el argumento "--disable-gpu" para obtener un desplazamiento suave.

No puedo creer que aún no esté resuelto ... Sufriendo esto por mi Surface book 2

todavía tengo que usar la solución para esto

@bpasero ¿Cuál es el estado de este error?

bpasero agregó esto al hito de diciembre de 2017 / enero de 2018 el 15 de diciembre de 2017

¿Significa que está previsto para la próxima versión (estable)?

Pensé que estaba arreglado, pero estaba mal. Probé en la compilación de vista previa de Visual Code. Funciona bien cuando abre el editor y está en modo de ventana (es decir, más pequeño que el escritorio), pero el desplazamiento se vuelve pegajoso cuando pasa a pantalla completa. El problema parece estar realmente relacionado con la pantalla completa. Además, la configuración del editor editor.smoothScrolling no funciona (creo que lo empeora cuando está habilitado).

Tengo el mismo problema en mi Surface Book 2.

Un recordatorio, para aquellos que no lo han visto, el problema está en el cromo. Por lo que puedo decir, la solución estará en electron 2.0, que aún no tiene una fecha de lanzamiento. El equipo de vscode tiene una "actualización a electron 2.0" en la iteración del mes actual, pero, por supuesto, no puede hacerlo hasta que se publique 2.0.

Hasta ese momento, realmente no hay nada que el equipo de vscode pueda hacer al respecto, pero tenga la seguridad de que la solución se convertirá en vscode tan pronto como esté disponible.

@EthanRutherford Por lo que dijo @bpasero , VScode está usando su propio Electron con algunos cambios personalizados, por lo que tal vez esto podría integrarse en VSCode sin tener que esperar a que se lance Electron 2.0.

@ nico-onmap No estoy 100% seguro, pero creo que se refería específicamente a los iniciados. Estable probablemente se construye con electrones sin modificar.

Tenemos una forma de realizar modificaciones en nuestra versión de Electron, pero todavía no he tenido tiempo de analizar esto. Además, la solución en Chrome es para Chrome Canary (¿Chrome 66?) Y usamos Chrome 58 ...

Tengo este problema en mi Dell XPS 15. ¿Hay ETA en la solución? ¿O la gente ya se está mudando a Atom?

Este problema de desplazamiento ocurre en mi Lenovo Yoga 920 ... me vuelve loco. Cambiar a un IDE diferente
¿Existe una solución alternativa además de minimizar y maximizar la pantalla cada pocos minutos?

@navotgil Prefiero maximizar y luego minimizar, si lo considera como una alternativa. Quizás la habilidad de desplazamiento permanece más tiempo en la forma minimizada, ya que a veces no tengo que hacerlo durante 20-30 minutos, supongo.

Estiro la forma minimizada para que se ajuste a la pantalla, así que la uso como si estuviera casi maximizada. Lo estiro desde las esquinas para evitar que la columna se rompa. Lo uso minimizado, porque tengo la superstición de que la forma maximizada es más propensa a plantear el problema.

Abra con code --disable-gpu en la terminal. Funciona para mi.

Abrir con el código --disable-gpu en la terminal funciona para mí.

@frenic ¡Realmente funciona! ¡Gracias!

Sí, lo mismo aquí; ¡funciona para mí también! Vaya, tan simple. ¿Por qué diablos no lo hice?
piensa en eso ;-)

El 20 de febrero de 2018 a las 16:04, 张义飞[email protected] escribió:

Abrir con el código --disable-gpu en la terminal funciona para mí.

@frenic https://github.com/frenic ¡Realmente funciona! ¡Gracias!

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/13612#issuecomment-367025826 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AI1HDgJ399foRiWQN2ZViILXKVDSLsx1ks5tWu0BgaJpZM4KU8A9
.

Abrir con el código --disable-gpu en la terminal funciona para mí.

@frenic increíble, gracias.
¿Alguien conoce las implicaciones que tiene sobre el rendimiento?

El parche está siendo respaldado gracias a chaopeng: https://github.com/electron/libchromiumcontent/pull/453

No pierdas la esperanza

Este problema está aquí desde que se publicó vs code, y se ha vuelto inutilizable vs code en Windows 10. Puedo entender que una pequeña empresa use electron para apuntar a múltiples plataformas a la vez, pero para una empresa como MSFT, realmente creo que es más nativo debe considerarse el enfoque. Sublime es multiplataforma, y ​​su rendimiento / fluidez está a la par con el bloc de notas. Microsoft realmente no debería hacer que el IDE de más rápido crecimiento dependa del producto de Google y de la capacidad de otras empresas para corregir errores para una plataforma específica.

Xi Editor en el repositorio Fuchsia es el futuro del editor. Todavía se está trabajando, pero la descripción es prometedora. Es multiplataforma, pero utiliza la biblioteca nativa de cada plataforma para lograr una apariencia nativa y ofrecer el mejor rendimiento. Tiene un aspecto mínimo y admite complementos. Ya salté del barco a lo sublime debido a su fluidez y suavidad. Xi será mi próxima opción una vez que se publique. El código VS es genial, pero estar basado en electrones hace que no quiera volver a tocarlo.

Había comprado este Surface Pro 4 a principios de 2016. Probé vscode tan pronto como me enteré, pero lo he estado evitando por sus problemas de desplazamiento desde entonces.

Recientemente comencé a usarlo nuevamente después de todos esos años en los que descubrí que el problema finalmente se está rastreando y ahora también tiene algunas soluciones. Solo puedo desear que las herramientas de desarrollo de Microsoft (VS Community y Code) fueran tan fáciles de introducir (táctil, trackpad, lápiz) como, digamos, Edge o Groove. Por otra parte, solo se puede hacer mucho con una aplicación Electron / Chromium. Mi problema es con el núcleo mismo de vscode.

Creo que está arreglado en la construcción de insiders.

@razielidog Patch se fusionó ayer en Electron 1.7.x: dudo que ya esté en la versión de insiders.

Espero que lo arreglan

esto es horrible. El desplazamiento del panel táctil tiene un retraso terrible en vscode. Surface Pro 5 + typecover.

Sí @razielidog , creo que acabas de mover la ventana (que es una solución). Se ralentizará de nuevo hasta que se incluya Electron 1.7 como dice @ nico-onmap.

He estado siguiendo esto durante 8 meses. Me encantan los productos de Microsoft, pero aparentemente, el panel táctil Precision de Microsost no funciona bien con el producto de Microsoft. Sé que es un problema de Chromium, pero aún así. Electron es realmente patético y he probado innumerables productos de Electron, ni uno solo es perfecto.

¿Cómo es esto un problema?

¿Pueden las personas que ven este problema darle una oportunidad a esta compilación interna? Descargar

Incluye un backport de la siguiente solución de Chrome para solucionar el problema: https://crrev.com/c/867070

@bpasero No, no resuelve el problema, pero una observación interesante. No tiene retraso en el inicio, pero después de minimizar, se comporta igual que la compilación de los internos.

@gurpreetshanky ¿puedes abrir devtools (desde el menú de ayuda) y en la consola escribir " process.versions " y enviarme el resultado de hacerlo?

@bpasero Esta es la salida
Objeto {http_parser: "2.7.0", nodo: "7.9.0", v8: "5.8.283.38", uv: "1.11.0", zlib: "1.2.11"…}

@gurpreetshanky Quise decir, escribe esto: process.versions["atom-shell"]

@bpasero "1.7.12"

@gurpreetshanky muy mal, veamos si otros informan algo más. Verificaré que el backport fue incluido en la compilación ... (la versión 1.7.12 es correcta al menos).

@bpasero Sí, pero definitivamente una mejora en el inicio. Además, When will vs code se actualizará a electron 2.0. En Atom touchpad funciona bien. ¿Por qué esto solo afecta al código vs?

@bpasero Probé la compilación en mi Surface Book y tengo el mismo comportamiento que @gurpreetshanky : funciona y se rompe nuevamente después de que la ventana se minimiza / restaura.

¿Alguien probó las compilaciones de Chrome con la solución: tal vez no se haya solucionado correctamente? Ha tenido errores durante años, no me sorprendería: /

Corrección: entendí mal el término minimizar como salir del máximo. Minimizar a la barra de tareas trae el problema aquí también.

@bpasero También lo probé en mi Surface Pro desde el enlace en el comentario y ya no tuve el problema. Minimizar / restaurar fue la solución alternativa que estaba haciendo para solucionar temporalmente el problema en la versión de lanzamiento, por lo que no entiendo cómo esta vez no se solucionaría, pero el problema volvería, de verdad ...

Sin embargo, incluso una sola verificación de que el problema persiste debería ser suficiente para decir que no está realmente solucionado, y tenemos dos. Probablemente no lo estoy activando de alguna manera.

@bpasero tengo que estar de acuerdo con ThoAppelsin, parece estar arreglado en esta compilación.
Intenté reproducirme y no pude

@bpasero Sí, pero definitivamente una mejora en el inicio. Además, When will vs code se actualizará a electron 2.0. En Atom touchpad funciona bien. ¿Por qué esto solo afecta al código vs?

Estamos pensando en actualizar a Electron 2.0.0, pero probablemente llevará más tiempo. Si desea verificar si el problema se reproduce en 2.0, puede probar con esta compilación de prueba ( enlace ), sin embargo, aún no incluye la solución.

No puedo explicar por qué no se reproduce en Atom ...

¿Alguien probó las compilaciones de Chrome con la solución: tal vez no se haya solucionado correctamente? Ha tenido errores durante años, no me sorprendería: /

Puedo hacerlo la semana que viene, también tenemos un caso reproducible con Chrome. Si ejecuta Chrome desde la línea de comandos apuntándolo a algún sitio web que se desplaza, podríamos hacer que el retraso aparezca directamente. La clave parece ser no escribir la URL en una pestaña, sino dejar que Chrome comience con una URL directamente.

@bpasero También lo probé en mi Surface Pro desde el enlace en el comentario y ya no tuve el problema. Intenté minimizar / restaurar para recuperarlo, pero no pude. Minimizar / restaurar fue la solución alternativa que estaba haciendo para solucionar temporalmente el problema en la versión de lanzamiento, por lo que no entiendo cómo esta vez no se solucionaría, pero el problema volvería, de verdad ...

@ThoAppelsin, ¿estás diciendo que este problema está solucionado incluso cuando minimizas / restauras la ventana?

@bpasero tengo que estar de acuerdo con ThoAppelsin, parece estar arreglado en esta compilación.
Intenté reproducirme y no pude

@razielidog y permanece fijo incluso cuando minimiza y restaura la ventana?

Igual que gurpreetshanky. No hay retraso en el inicio, pero min / max lo devuelve.

@bpasero Mi mal. Entendí mal la terminología y probablemente también confundí a entendí mal la salir de la maximización , y eso no

Minimizar la ventana a la barra de tareas y restaurarla también trae el problema de vuelta.

@bpasero ¿Se Version 65.0.3325.146 (Build officiel) (64 bits) exhibe el problema cuando se inicia desde la línea de comandos con un sitio web como parámetro (y desaparece cuando se abre una nueva pestaña, pero creo que esto se sabía).

Editar El problema se solucionó en las compilaciones de Canary ( Version 67.0.3367.0 (Build officiel) canary (64 bits) ) y definitivamente se solucionó: minimizar / restaurar no recupera el problema. Así que aún no se ha estabilizado.

@ThoAppelsin al menos todos tenemos el mismo comportamiento.

@warpdesign Creo que solo está en Chrome 66, ¿puedes probar con su versión beta para ver el comportamiento? Gracias por probar esto 👍

@bpasero probó Chrome Beta y Canary, aquí están los resultados:

• Beta (65.0.3325.125): hay un error, el mismo comportamiento que VSCode estable (el desplazamiento se retrasa, minimizar / restaurar temporalmente lo corrige)
  
  
  
  • Canary (67.0.3367.0): el error está definitivamente solucionado: minimizar / restaurar no lo devuelve
  
  

Entonces, parece que el parche que aplicó revirtió un poco el problema, es decir, está solucionado de manera predeterminada y restaurar / minimizar lo devuelve.

Puedo confirmar que Atom ( 1.24.1 ) no presenta el problema que está usando Electron 1.6.16 .

¿Qué tal cooperar con Atom ya que no tienen el problema? ¿Lo tenían ellos? Si es así, ¿cómo lo arreglaron? ¿Si no, porque no?

@warpdesign tendrías que probar con Atom Beta ( 1.25.x con Electron 1.7.11 ) aunque para que coincida con la misma versión de Chrome que estamos usando. Es posible que Electron 1.6.x no tenga este problema después de todo porque usa una versión anterior de Chrome.

Estoy tratando de hacer un seguimiento con Electron si su backport tal vez no esté completo (discusión en https://github.com/electron/libchromiumcontent/pull/472).

¡Gracias por el trabajo en esto!

@bpasero Acabo de probar con Atom Beta ( 1.25.0-beta3 , Electron 1.7.11 ) y el desplazamiento funciona perfectamente: sin retrasos, no hay problema al minimizar / restaurar.

@warpdesign hmm Entonces, ¿el error está en la base del código vscode?

@gurpreetshanky realmente no puede decir eso porque este error se reproduce en Chrome y se confirmó que era un problema con Chrome y ellos lo arreglaron mientras tanto. Sin embargo, no me queda claro cómo Atom no desencadena el problema y no está claro por qué la solución funciona en Chrome pero no para nosotros después de minimizar / restaurar.

@bpasero ¿ tal vez la corrección de errores se basa en otras correcciones / cambios que no se aplicaron? ¿Qué le parece ponerse en contacto con la persona que envió los parches de Chrome para este error?

@warpdesign para ser justos, este parche se aplicó sobre Chrome 66 y lo vamos a poner sobre Chrome 58, por lo que bien podría ser que falta algo más ...

¿Pueden las personas que ven esto en estable confirmar que el problema volverá una vez que minimice y restaure? Estoy tratando de entender que si siempre tuvimos ese problema con la minimización / restauración, el problema vuelve.

Mis pruebas con Surfacebook parecen indicar que este problema existía antes. Lo que significa que el backport lo corrige al inicio, pero no es peor que antes con respecto al problema que vuelve a minimizar / restaurar.

Sí, existe en la construcción estable actual (minimizar + restaurar hace que el desplazamiento sea lento):

Versión 1.21.0
Confirmar 9a199d77c82fcb82f39c68bb33c614af01c111ba
Fecha 2018-03-07T11: 04: 09.969Z
Shell 1.7.9
Procesador 58.0.3029.110
Nodo 7.9.0
Arquitectura x64

(al menos en mi Dell XPS 15 9560)

En mi opinión, incluso esta solución parcial sería buena para fusionarla con información privilegiada hasta que se solucione el error de minimización. Desde el punto de vista de la usabilidad al menos.

@ynotzort, ¿también vuelve con otros gestos en la ventana? ¿Te gusta cambiar entre ventanas de aplicaciones? Lo pregunto porque minimizar / restaurar parece una tarea ejecutada con menos frecuencia en comparación con cambiar de Windows.

@bpasero no lo parece, al menos alt + tab y windows + tab no hacen que me aparezca el problema.
Sin embargo, el uso de windows + d (minimizar / restaurar todas las ventanas) hace que aparezca, lo cual es bastante molesto ...

Solo agrego que tengo este problema en la última versión 1.21.0 incluso antes de minimizar / restaurar. Si abro un archivo en VS Code, el desplazamiento es entrecortado con el panel táctil. He puesto:
"window.menuBarVisibility": "toggle"
Entonces, mi solución rápida es presionar ALT, lo que hace que la barra de menú aparezca y el problema desaparezca. Eso es hasta el ciclo de minimizar / restaurar cuando regrese.

@marchom Gracias por el consejo, lo prefiero a cambiar el tamaño como solución.

Parece que el comportamiento de los errores sigue este patrón en 1.21.0 (Windows):

• Aparece
  
  
  
  • en el inicio
  
  
  • después de minimizar / restaurar cuando se maximiza (ya sea con botones o Win + D )
  
  
• Desaparece
  
  
  
  • al iniciar vscode con --disable-gpu bandera
  
  
  • en cambiar el tamaño
  
  
  • mientras sostiene CTRL o ALT
  
  
  • después de tocar ALT (solo si tiene la barra de menú oculta)
  
  
  • después de alternar el modo de pantalla completa ( F11 )
  
  
  • si las herramientas de desarrollo están abiertas Help -> Toggle Developer Tools
  
  
• Sin efecto
  
  
  
  • después de minimizar / restaurar cuando vscode está enfocado, pero no maximizado
  
  
  • ALT + TAB
  
  
  • Win + TAB
  
  

Tocar dos veces F11 (alternar pantalla completa) también me elimina el problema. Ejecutar code --disable-gpu funciona ...

Lo que es extraño es que si VSCode no está maximizado, entonces minimizar y restaurar no desencadena el problema para mí ...

Tuve el problema con Discord que también usa Electron .
(No puedo relacionarme más porque trabajo el 80% de mi tiempo en Linux)

Lo que es extraño es que si VSCode no está maximizado, entonces minimizar y restaurar no desencadena el problema para mí ...

@ynotzort Puede confirmar este comportamiento. Actualicé mi lista

Utilizo maximizar / restaurar o restaurar / maximizar como solución alternativa, y funciona (por lo que recuerdo) todo el tiempo. ¿Quizás esta solución alternativa podría emitirse mediante programación cada vez que vscode se muestre desde la barra de tareas después de minimizarse?

No estoy lo suficientemente informado sobre estos temas, pero tal vez se pueda hacer de manera lo suficientemente atómica, sin que se vuelva a dibujar la ventana. Hasta que la solución llegue y se propague desde el cromo / electrón hasta el vscode, vscode podría tenerlo parcheado así como una medida temporal.

@ pd93 También noté que Help -> Toggle Developer Tools también mitiga el problema. Por algunas razones, si las herramientas de desarrollo son visibles, los retrasos nunca ocurren.

@karasq Gracias, puedo confirmar esto. Solo puedo asumir que tener las herramientas de desarrollo abiertas está causando un cambio de tamaño cuando te enfocas en vscode. Aunque no tengo nada que respalde esta teoría.
Lo he agregado a mi lista ^^^

@karasq gracias, Ayuda -> Toggle Developer Tools funcionó para mí,
y el código --disable-gpu funcionó también

@bpasero acabo de ver eso en las notas de la versión de electron 1.7.13 "Soporte fijo para el desplazamiento de precisión del trackpad / mouse". está resaltado. ¿Quizás esta versión podría usarse en lugar de la 1.7.12?

@razielidog usamos 1.7.12 pero con ese parche exacto retroportado ...

Con la compilación de información privilegiada de hoy ( 3a70cdfd8f84136e858b3d39e5a709e637fc35e7 ) puede configurar "window.smoothScrollingWorkaround": true para volver al desplazamiento suave al restaurar la ventana. Esta compilación también incluye una versión de Electron que solucionará este problema en el inicio inicial.

Háganos saber cómo va. La razón por la que esta nueva configuración no está habilitada de forma predeterminada es a) es solo una solución alternativa y no la solución real todavía b) da como resultado un parpadeo de la ventana cuando la restaura.

@bpesaro ¡ buenas noticias! No tengo acceso a mi libro de superficie en este momento, lo probaré en unos días. ¿El parpadeo significa que el parche se vuelve a aplicar cada vez que se restaura la ventana?

@warpdesign, el parpadeo proviene literalmente del hecho de que con esa opción habilitada, alterno la visibilidad de la barra de menú cuando se restaura la ventana. Sin embargo, esto no sucederá en el inicio inicial.

@bpasero Workaround funciona como se esperaba en mi Surface Book, no más demoras después de minimizar / restaurar.

Parece que el problema tiene algo que ver con la versión de Windows (especialmente el touchpad de precisión). Si ejecuta el código VS en el modo compatible de Windows 7, el retraso de desplazamiento desaparece y ya no volverá a aparecer.

@ TXH1997 Gracias por la idea del modo de compatibilidad. El modo comp. De Windows 7 parece solucionar permanentemente mis problemas de retraso de desplazamiento (en Surface Pro 4).

@ TXH1997 porque ejecutarlo en modo de compatibilidad significa ejecutar sin GPU. Así que funciones como la terminal integrada no funcionarán.

Sí, es solo una solución temporal. El error queda por solucionar ...

Con la esperanza de solucionar este problema desde hace mucho tiempo, no entiendo por qué la EM no puede dar una solución adecuada.

Viendo esto actualmente en un Surface Book en la versión 1.21.1

Bloquearé este problema para que la gente pueda ver la solución actual que enviamos con 1.22:

Estoy desbloqueando este problema para obtener algunos comentarios sobre el hecho de que Windows 10 ha estado trabajando en una solución y parece estar incluido en Windows 10 Insider Preview Build 17751 y se incluirá en la actualización de octubre (RS5).

Si alguien pudiera verificar que el problema está realmente solucionado con esa compilación de información privilegiada de Windows 10, sería genial. Hasta ahora escuché de @Drae en https://github.com/Microsoft/vscode/issues/53793#issuecomment -417922382 que el problema se resolvió.

Para verificar:

• actualización a Windows 10 Insider Preview Build 17751
• eliminar la configuración window.smoothScrollingWorkaround (si está configurado)

@bpasero Ya

@bpasero Sí, el problema se resuelve con 17751.1 en Dell XPS 15 con panel táctil de precisión.

Por curiosidad: ¿Alguien ha encontrado este problema en Windows 7 o Windows 8? Lo pregunto porque la solución probablemente solo se hará en Windows 10.

@bpasero No creo que suceda en versiones anteriores de Windows porque no mal no recuerdo.

¿Este cambio estará presente en la actualización de Windows 10 de octubre de 2018 cuando se lance?

Mi computadora de escritorio hp está encendida durante un minuto, pero los monitores no están abiertos y el mouse o el teclado no funcionaban cuando actualicé mi Windows 10 hace dos años

@ bdr99 sí, estará disponible como parte de la actualización de octubre.

Cerrando esto cuando la actualización de octubre de Windows 10 se está implementando para las personas. Este error se corrigió como parte de la actualización de Windows 10 RS5.

Impresionante, ahora tengo que esperar a RS5, con suerte mañana.

Decidimos mantener el "window.smoothScrollingWorkaround": true para esta versión y planeamos eliminarlo en el futuro cuando más usuarios actualicen a la última versión de Windows.
¿Alguien que no tenga la última versión de Windows 10 puede tomar esta compilación interna y verificar que window.smoothScrollingWorkaround funciona como antes y que el desplazamiento es fluido? Yo realmente lo apreciaría.

https://az764295.vo.msecnd.net/insider/1d0e4299c6ccfe9210252c811b4247cfdc8a6a44/VSCodeSetup-ia32-1.29.0-insider.exe
https://az764295.vo.msecnd.net/insider/340133accd0b66202bde342f995f00b02f63c0d4/VSCodeSetup-x64-1.30.0-insider.exe

@isidorn Todavía no tengo instalada la actualización de octubre, así que instalé la compilación interna para probar.

Pero la cosa es que la actualización KB4462933 solucionó el problema por mí. Ahora no hay diferencia entre las compilaciones estables / internas y con / sin window.smoothScrollingWorkaround después de la actualización.

Aquí hay más testimonios: https://github.com/Microsoft/vscode/issues/62327#issuecomment -436597428, https://github.com/Microsoft/vscode/issues/61824#issuecomment -433785824.

@HazemAM ¡ gracias por saltar!
Es por eso que necesito que alguien que no tenga la última actualización de Windows lo pruebe para que podamos verificar que la configuración aún funciona.

@isidorn Oh, ¿entonces te

Sí, supongo que necesito a alguien que no tenga https://support.microsoft.com/en-us/help/4462933/windows-10-update-kb4462933

Tenga en cuenta que no es suficiente configurar window.smoothScrollingWorkaround: true , también tendrá que deshabilitar el título personalizado a través de window.titleBarStyle: native .

No tengo actualizaciones de Windows disponibles para instalar (estoy actualizado), el último vscode y estoy ejecutando bootcamp windows.

Al usar el trackpad, no hay absolutamente ninguna forma (con cualquiera de las combinaciones de sugerencias en este hilo) para que el desplazamiento funcione sin problemas. Vscode ignora la configuración de la rueda del mouse del panel de control. La única forma en que puedo hacer que vscode se comporte es configurando el "editor.mouseWheelScrollSensitivity": 0.2 sin embargo, cambio entre usar un trackpad y un mouse, ¡así que tengo que cambiar esta configuración cada vez que cambio de dispositivo!

¡Por el momento, vscode es bastante insoportable de usar debido a esto!