Cinnamon: Retraso de redibujo de ventanas al arrastrar ventanas

Odio decir "yo también", pero ... "¡Yo también!" Estoy ejecutando una caja algo más antigua, con Cinnamon ejecutándose sobre Ubuntu 13.04. Todo lo demás parece estar bien, solo el arrastrar la ventana es un problema. Y el "tartamudeo" es notable, después de lo cual la ventana simplemente salta al siguiente punto. Parece suceder al arrastrar cualquier ventana (chrome, uxterm). Hágame saber qué otra información de apoyo puedo proporcionar. No encuentro nada interesante en los registros de mi sistema.

Puedo confirmar esto, pero tengo una tarjeta gráfica muy pobre ...

Yo también estoy experimentando estos mismos problemas. Estoy ejecutando la última versión de Cinnamon del ppa nocturno en Ubuntu 13.10.

Actualmente ejecuto un sistema multicabezal en arch linux con cinnamon 2.0.2 (3x 1920x1080). He probado tanto el 660 como el 7870. Ambos muestran el mismo comportamiento, ventanas extremadamente retrasadas cuando se mueven o ajustan el tamaño. Estoy usando el cajero automático de controladores de código abierto. (Probaré el catalizador una vez que estén actualizados para funcionar)

En mi sistema es casi insoportable.

--- Actualizar --- si desactivo en el panel de Configuración de Cinnamon -> Mosaico de ventana y volteo de borde -> Mosaico de ventana y ajuste - las ventanas se mueven de nuevo rápidamente por la pantalla; Obtuve esta pista moviéndome alrededor de una ventana y obtuve el nuevo HUD mostrándome la posición en la que podría colocar esa ventana; cada vez que aparece el HUD, el retraso se inicia.

Puedo confirmar el mismo comportamiento en mi computadora portátil; usando Manjaro Linux y Cinnamon 2.0.6
Tengo una CPU P6100 de doble núcleo y una tarjeta gráfica Intel HD 3000.
No tuve este problema antes con 1.6 o 1.8.
Estaba buscando una opción con Muffin para deshabilitar el "contenido de la ventana" mientras me movía, pero no tuve suerte hasta ahora, usando el editor Dconf.
Sería fantástico si alguien explicara por qué sucede esto.
¡Sigan con el buen trabajo;)!

El retraso en el arrastre de Windows no es nada comparado con el cambio de tamaño de las ventanas (por ejemplo: gnome-terminal), puede tomar varios segundos :-(

Confirmo este error con Intel core I5 ​​y el controlador gráfico Intel (segunda generación).

Puede establecer el umbral de mosaico del HUD en 1 y esencialmente deshabilitará la visualización del HUD mientras mantiene habilitado el mosaico. Tal vez en la próxima versión se pueda agregar una forma más directa de deshabilitarlo, junto con un conjunto de gráficos más robusto para animar el HUD.

Puedo confirmar este error en la CPU i7-2600K y la GPU AMD R9 290 (últimos controladores beta). Particularmente en mi pantalla de 120 hz. Deshabilitar el mosaico y el ajuste no ayudó.

¿Qué versión de Cinnamon estás ejecutando? Una de las causas de esto fue parcheada hace relativamente poco tiempo.

https://github.com/linuxmint/muffin/commit/403d24edc854c6610ff46427b6cf2072fa62bfa5

Estoy ejecutando Cinnamon 2.0.14. Intentará instalar la última versión.

Probablemente sea más importante tener el último muffin. Si está en muffin 2.0.4, aún no tiene la solución. Si ejecuta 2.0.5 lo tendrá.

(No garantizo que su problema particular se solucione, podría ser posiblemente otra causa, pero vale la pena verificarlo)

Estoy experimentando algo similar con Cinnamon 2.0.14 y Muffin 2.0.5 en Mint 16 con un i5-4440s con gráficos Intel HD 4600. Cuando arrastro Windows, no pueden seguir el ritmo del cursor del mouse. Es como si las ventanas estuvieran unidas a mi cursor con una pequeña banda de goma.

Aquí hay un video de lo que estoy experimentando. ¿Es este un comportamiento normal? http://youtu.be/KylzMTZpD7w

Puedo confirmar que este caso sigue siendo válido para Cinnamon 2.2.14 y también para Gnome Shell 3.12.2 en Debian Jessie.

También entiendo esto y, para ser honesto, me distrae mucho. Notablemente menos suave que Unity, etc., y de hecho Windows ...

Experimentar lo mismo de lo que me quejé anteriormente, pero también con una NVidia GTX 760. El problema es definitivamente peor con varios monitores.

También obtengo esto en Cinnamon 2.2.14, con una NVidia GT 630 con la versión de controlador propietario 340.24 (y dos monitores). Al degradar a la versión 304 del controlador, las ventanas se mueven rápido nuevamente, pero luego se rompen.

El domingo 10 de agosto de 2014 a las 04:04:47 a.m. EEST, Andres Manz escribió:

También obtengo esto en Cinnamon 2.2.14, con una NVidia GT 630 con el
controlador propietario versión 340.24 (y dos monitores). Al degradar
a la versión 304 del controlador, las ventanas se mueven rápido nuevamente, pero luego
experiencia de desgarro.

El retraso de arrastre de la ventana desaparece cuando vsync está deshabilitado a través del
Variables de entorno. AFAIK Nvidia driver 304 no habilita vsync por
predeterminado (a diferencia de los más nuevos), por lo que puede explicar por qué tiene
arrastrando y rasgando cuando bajes a él.

Sin embargo, el uso elevado de CPU prevalece independientemente de vsync.

Puedo confirmar que Windows es mucho menos lento si no intento habilitar vsync (controladores Intel), pero los videos no se pueden ver.

También es extraño que linux mint no tenga este error, y arch linux sí.

@startas No, lo conseguiré en Mint 17.

Aún más extraño desde que publiqué en este número, no he vuelto a tener el problema. Desde entonces, he instalado Cinnamon en varias configuraciones de dispositivos, hardware y software (distribuciones) diferentes.

Es extraño: "resolví" este problema (solo tengo gráficos Intel HD, por lo que solo podría funcionar para gráficos Intel) recompilando xf86-video-intel con el indicador "--disable-dri3" y volviendo a compilar lib32-mesa con el mismo flag "--disable-dri3", por supuesto, también debe eliminar el flag "--enable-dri3".
Mientras estoy usando Linux de 64 bits, compilar el paquete Mesa de 64 bits sin dri3 e instalarlo bloquea el escritorio de Cinnamon, pero de alguna manera recompilar solo xf86-video-intel y la versión de 32 bits de Mesa para sistemas de 64 bits "solucionó este problema", también arreglos enormes retrasos en cromo.
Solo deshabilitar dri3 en controladores 2d no funciona, pero deshabilitar dri3 en la versión de 32 bits de mesa e instalarlo funcionó, me pregunto por qué: este paquete ni siquiera está instalado de forma predeterminada, ya que Linux de 64 bits usa canela de 64 bits, por lo que usa 64 bits mesa, y no tengo idea de cómo funcionó: D

excepto que hay un problema con eso, DRI3 no existía cuando se creó este problema por primera vez.

Actualmente arch linux también diable DRI3 por defecto, creo?

Este problema parece estar relacionado con algo que veo en Kerbal Space Program en Linux (con Cinnamon): marcos perfectos, excepto cuando hago clic y mantengo presionado el mouse para desplazarse por un cohete, luego tartamudea y salta mal. ¿Cinnamon quizás esté bloqueando el ciclo de redibujo de los eventos del mouse?

En arch linux, xf86-video-intel se compila sin dri3, pero mesa se compila con dri3.

en mi PC bastante rápido, cambiar el tamaño de las ventanas con canela es una molestia y me encantaría una opción para desactivar la visualización en tiempo real del contenido de la ventana. xfce hace esto de una manera muy buena.

Esto está sucediendo, pero solo en mi monitor externo, en una Macbook ("finales de 2014") con gráficos Intel. La ventana también mostrará artefactos de desgarro, nuevamente solo en la pantalla externa. El retraso no cambia notablemente si habilito "TearFree" pero corrige el desgarro. Estoy escalando la pantalla externa hasta 2x2 con xrandr.

editar: Debo señalar que algo como glxgears no sufre una reducción de la velocidad de fotogramas si lo arrastro en esa pantalla, de hecho, estaba reportando ~ 71 fps en un monitor de 60Hz, a pesar de que el movimiento lo hace parecer <10 fotogramas por segundo. Dejándolo solo, funciona normalmente.

edit2: parece que la escala tampoco cambia el retraso.

@wrouesnel y otros ...

El problema de KSP específicamente se debe probablemente a que la tasa de sondeo de su mouse está configurada demasiado alta, particularmente si tiene un mouse para juegos, como un Razer DeathAdder o similar (que yo uso). El siguiente tutorial debería ayudar:

https://patrickmn.com/aside/lowering-gaming-mouse-sensitivity-in-ubuntu-9-10/

Grabé un video que muestra el problema que tengo (problema de arrastre del navegador Chromium, mientras que Nemo y Firefox se ejecutan solo para comparación): https://youtu.be/Ec99EYjwiqY
Tengo el mismo problema con IntellJ y, a veces, con Pidgin o menos veces con Nemo. Estoy usando Mint 17.3 y Cinnamon 2.8.6 con controladores propietarios amd. Cosas a tener en cuenta:

-Menta 17.3 con Canela 2.8.6
-no pude cargar controladores de gpu de código abierto para probarlos, me mantuvo en modo de renderizado de software ahora (recuerdo que el código abierto de xorg funcionó bien cuando instalé 17.0 Mint hace unos meses)
- Forzar vsync deshabilitado en CCC propietario de amd ayuda a ventanas un poco menos retrasadas, pero hace que la pantalla se rompa especialmente al desplazarse por sitios web
-Cuando Cinnamon acaba de comenzar, todo funciona bien, sin ventanas de arrastre demoradas, sin cambio de tamaño demorado. El problema está presente después de un tiempo (por ejemplo, 10-40 minutos después de que se inició Chromium)
-Reiniciar Cinnamon (ctrl + alt + esc) ayuda temporalmente (punto anterior)
- (editar): no sucedió antes en 17.2 y Cinnamon 2.6 si no recuerdo mal, pero tenía un problema de desgarro mayor en ese entonces.

Editar:
Lo mismo sucede con los controladores de código abierto, logró reinstalarlos.

Ejecutando Fresh Mint 17.3 Cinnamon desde una memoria USB, el mismo problema que se explicó anteriormente.
Verificó Ubuntu Gnome3 y Ubuntu Mate para comparar. Mientras ejecuto ambos desde USB durante bastante tiempo, no he notado ningún problema / ralentización.

De alguna manera parece que está relacionado con la GPU, sucede especialmente con el software que tiene soporte de GPU, como Chromium.
La segunda cosa a tener en cuenta es que parece que sucede más rápido mientras se tiene intelihide para la barra de menú y sigue presionando la barra de menú con la ventana de Chromium. Puedo escuchar a los ventiladores en la computadora portátil comenzar a trabajar más fuerte. Lo mejor es arrastrar la ventana de Chromium circulando por el escritorio.

"Deshabilitar la redacción para ventanas de pantalla completa" habilitado / deshabilitado: sin cambios

Es lento para repruducir incluso con la barra de menú perforada, la forma más fácil es simplemente navegar por Internet durante un tiempo, pero entiendo que podría ser un infierno para la depuración.

También tengo este problema, pero lo que noté es que las ventanas se ponen _laggy_ después de un tiempo, pero si abro otras nuevas, no _lag_.

Por ejemplo, si dejo que un terminal permanezca allí durante una hora, tartamudeará mientras se arrastra un poco, pero un terminal recién abierto se comportará bien.

Y sí, ahí es cuando tengo Chrome abierto (que básicamente está abierto todo el tiempo).

No es gran cosa, ya que todos los demás aspectos parecen funcionar bien (por ejemplo, no notas más demoras en los juegos o algo así); la única otra cosa extraña que noté es que la pantalla de bloqueo tarda unos 10 segundos. para cargar (nunca me di cuenta de eso antes de actualizar a Mint 17.3)

PD: Me di cuenta de que el proceso cinnamon --replace mostrará un uso de CPU bastante alto (alrededor del 16% en mi sistema) algún tiempo después de mover una ventana _laggy_.

Intellihide deshabilitado, configura el panel para que se muestre siempre. Funcionando actualmente OS durante unas horas y ¡sorpresa! ¡sin retrasos! Me siento como en el cielo.

Puedo confirmar el retraso de la ventana detrás del cursor, en Linux Mint 17.3, Cinnamon 2.8.6, con el controlador propietario nvidia 352.63. ¡Muy molesto! ¡El problema es independiente de la composición habilitada o no!

También puedo confirmar el retraso con Mint 17.3, Cinnamon 2.8.6 y gráficos integrados de i5-4210U o una nVidea GeForce 820M.
Jugué un poco con la configuración de mostrar / ocultar el panel y parece que el retraso solo está ahí cuando se muestra el panel. Cuando lo configuro para ocultar automáticamente todas las ventanas arrastradas son suaves.
(Sí, sé que esto es todo lo contrario del comentario de DarekDeo).

Tal vez no sea todo lo contrario, según nuestros comentarios, parece que algo anda mal con el panel. :)

editar: o al menos relacionado con él.

Yo también tengo este problema. ¿Alguien prueba un controlador de gráficos diferente? Tuve este problema en Xubuntu 15.10 y una vez que cambié el controlador, todo funcionó bien. ¿Parece que no puedo encontrar esa opción aquí? Voy a los controladores en el panel de configuración y aparece una lista en blanco.

Configuración: Fedora 23, Cinnamon, GDM, controladores patentados de Nvidia (también con Nouveau)

También estoy experimentando tartamudeo al arrastrar ventanas, y también al escribir o desplazarme por un archivo en Vim. Por ejemplo, mientras escribo, aparecerán algunas letras con la pulsación de tecla, luego el cursor se colgará durante unos milisegundos y luego aparecerán todas las letras que escribí durante el bloqueo.

La tartamudez parece ocurrir con regularidad. Si tuviera que adivinar, diría aproximadamente cada 500 ms. Curiosamente, si muevo una ventana rápidamente durante un período de tiempo, la parte superior muestra que Xorg a veces toma un gran porcentaje de la CPU (~ 53%) al mover ventanas ... esto no parece correcto. ¿Algunas ideas?

EDITAR: Arranqué el CD en vivo de Cinnamon Spin de Fedora 23 y, curiosamente, no encontré ningún tartamudeo. Pero, al usar el mismo entorno DM (controladores Cinnamon, lightdm, nouveau) en mi instalación de HDD, todavía lo hace. Puedo intentar instalar Cinnamon directamente desde el Live CD en una máquina diferente para ver si el problema persiste; Informaré con los resultados.

Vaya, vale. Gracias @DarekDeo, esto funciona mucho mejor cuando el panel inteligente está desactivado. Es una pena que no pueda ver videos de Youtube en el reproductor grande cuando mi navegador está en pantalla completa ahora, razón por la cual encendí ese panel en primer lugar, pero las ventanas estaban empeorando.

Sin embargo, me parece extraño lo retrasadas que son todas las ventanas, no son insoportables, pero si vuelvo a Windows, mi 144hz hace que todo se vea y se sienta tan suave, moviendo las ventanas y todas se sienten tan sólidas y estables, vuelve Linux y mi 60 casi se sienten más suaves que mi 144 y Windows se siente como si estuvieran retrasados ​​cuando los arrastra.

También solo quiero agregar que el panel inteligente parece afectar también a las ventanas, mi navegador había estado parpadeando en blanco por completo al fallar mucho, revisé algunos probándolos para ver cuál ya no lo experimentaba, pensé que algo podría ser roto con canela o mi controlador de gráficos, resulta que el panel era el problema @ _ @

Bueno, eso es interesante, noté que el tartamudeo que estaba viendo parecía ocurrir con la misma frecuencia con la que se actualizaba el subprograma del Monitor del sistema, así que lo quité del panel y reinicié, y ahora el tartamudeo desapareció para mí. Esto parece respaldar aún más la sugerencia de @DarekDeo de que algo podría estar mal con el panel. Tal vez, cualquier proceso / cosa que se esté actualizando, se cuelga brevemente durante su ciclo de redibujo (no soy un programador de gráficos).

En realidad, tengo el mismo problema, actualizar a una versión más nueva de Cinnamon lo hizo un poco mejor, pero mi computadora de escritorio Nvidia (i5-3570k, Nvidia 780ti) todavía no es tan fluida como mi computadora portátil con gráficos Intel mucho menos potente (i7-4500u, Intel gráficos 4400).

Ambos ejecutan Mint 17.3, Cinnamon 3.04 (canal nocturno) y el kernel 4.4.0-22.

Los controladores utilizados son el 364 de Nvidia (364.19-0ubuntu0 ~ gpu14.04.3) del PPA de controladores de Nvidia y los controladores de Intel incluidos en el kernel.

@ davidva-cml gracias, ¡la eliminación del subprograma Sytem Monitor solucionó el problema para mí!

Desactivó "sincronizar con vblank" en la configuración de nvidia xserver y cambiar el tamaño de aplicaciones como Telegram ahora es suave como la mantequilla

Esto sigue siendo un problema para mí.
Estoy usando una instalación nueva de Ubuntu 16.04.1, usando una Nvidia GTX 1070 con la versión del controlador 375, por lo que el rendimiento no debería ser un problema.

@JosephMcc , ¿podemos marcar este problema como un error?

@ davidva-cml ¿Lograste arreglarlo? También veo a Xorg en la parte superior del uso de la CPU al arrastrar ventanas ... Tal vez deberíamos informarlo como un problema de Xorg. Aunque, después de todo, siempre podría ser un problema de Cinnamon ... La forma más sencilla de reproducir es ejecutar glxgears en el fondo mientras arrastra las ventanas.

Sin embargo, algunas personas dentro de este problema podrían sufrir un problema de retraso totalmente diferente (que podría estar relacionado con la canela).

Me temo que tengo el mismo problema. Pero tengo una PC realmente poderosa (Core i7-5930K 3.5GHz 6 núcleos + Nvidia TITAN X con el último controlador nvidia + 32 GB de RAM y mi sistema operativo está instalado en un SSD). Así que las actuaciones no deberían ser un problema. Pero aún así, cada vez que intento arrastrar una ventana, tengo lentitud como todos los demás en este hilo. ¡Pero las aplicaciones más abiertas que tengo son más lentas!
Cuando superviso (htop) puedo ver que el proceso de Xorg consume el 90% o más del uso de la CPU. Entonces podría provenir de Xorg, no de canela directamente.
Debería ser bueno tener comentarios para comprender lo que está sucediendo allí.
Gracias.

Corriendo :
Kernel de Linux 4.10.0-genérico
FerenOS (que utiliza la última versión de la distribución Linux Mint)
Ejecutando canela 3.4.6

Tengo curiosidad por saber si otros han descubierto alguna solución para esto últimamente, ya que se ha quedado en silencio.

Para mí, Cinnamon comienza a desestabilizarse con este retraso que crece desde el reinicio con el tiempo, hasta que se vuelve casi demasiado molesto para tomarlo más, y generalmente encuentro que tengo que reiniciarlo con fuerza ya que la pantalla ya no se despierta del modo de suspensión. Como la última publicación, es una computadora poderosa (20 núcleos, 40 subprocesos, dual xeon, 128 gb de ram, nvidia 1070, dual nvme, pantallas 3x 4k), por lo que el rendimiento no es un problema, y ​​no obtengo esto con otras computadoras de escritorio entornos distintos de kde (que tiene sus propios problemas de composición). Apagué vblank y la mayoría de las otras funciones de gl, y aún así se desestabiliza, generalmente dentro de una semana, pero nunca ningún error que indique algo.

Estoy usando los controladores Arch linux, Cinnamon 3.8.1-1, 4.16.13 kernel y nvidia 396.24. Sigo actualizando con la esperanza de que esto desaparezca, pero nunca lo hace.

Aparentemente (como ocurre con la mayoría de los escritorios ahora), la respuesta es simplemente usar la representación de software del escritorio. Me las arreglé para ir unas semanas antes de que tuviera un tiempo de espera de visualización de 5 segundos aproximadamente cada minuto, lo que se vuelve bastante irritante con el tiempo.

Por lo general, simplemente cambio a un escritorio diferente, KDE (rezando para que lo arreglen también) o Mate (marco tiende a comportarse, pero el escritorio no se encuentra en comparación con otros) después de un pacman -Syyu, pero esta vez noté que el software de canela se procesa modo. Después de una semana de uso normal con el renderizado de software, normalmente comenzaría a tener el retraso después de unos días, pero con el modo de software, ha sido fluido y realmente no veo inconvenientes en el rendimiento en el uso de escritorio.

Es una pena que este error del compositor parezca persistir, pero es casi seguro que esté relacionado con video / gl. Los compositores son la pesadilla de todos los escritorios de Linux que encuentro, todavía tengo que encontrar uno que se comporte correctamente, incluso windoze aero que encontré en 4k es una absoluta mierda que se envió con mi xps 9560.

Una buena solución es agregar CLUTTER_VBLANK=none a / etc / environment y habilitar la canalización de composición forzada en todos los monitores en nvidia-settings en Configuración de pantalla -> Avanzado. Esto mueve el manejo de vsync del compositor al controlador, y también ayuda en amdgpu con TearFree habilitado en la configuración de xorg.

Gracias por eso, configuré mi entorno / etc /, pero no encontré la necesidad de probar la versión renderizada por hardware, ya que solo parece invitar al drama y al caos. Estoy bastante contento con la versión renderizada por software hasta ahora, algunos retrasos en el dibujo en cairo-dock y algunas otras aplicaciones, pero no tanto como la versión de hardware que se caca sobre sí misma.

Es interesante, incluso en el modo de software ahora, estoy desarrollando el mismo retraso, pero a un ritmo mucho más lento que con el renderizado completo de gpu. Se siente como una especie de fuga de recursos, pero si no se renderiza directamente contra la gpu, presumiré algún error en la administración de recursos dentro del escritorio.

¿Qué comentarios, registros, depuraciones, etc. son útiles para ayudar a solucionar este problema? No veo nada anormal en ninguna parte, aparte de que el escritorio se vuelve loco a intervalos aleatorios / comunes.

También para aclarar, creo que mucho de esto tiene que ver con las altas resoluciones en las que lo uso. Mi escritorio funciona a 11520x2160 (3 pantallas de 4k), lo que grava cualquier escritorio que encuentre que incluso intente la aceleración de gpu. No creo que nadie tenga en cuenta ese tipo de cosas, pero con 4k, 5k y ahora 8k llegando, la lucha es real. Esta es la razón por la que la composición parece romperse en cualquier escritorio, incluidos unity, kde, cinnamon o incluso mate / marco con renderizado directo contra gpu a esta escala.

Es algo a tener en cuenta para los desarrolladores, la escala de resolución para el renderizado compuesto correctamente ha sido un problema desde ~ 2010 cuando ejecutaba pantallas de 6x 1080p en Linux con la llegada de la composición.

Así que volví de nuevo para verificar esto, después de experimentar retrasos de 5 segundos en el redibujado de ventanas bajo la composición del software más recientemente después de alrededor de 80 días de tiempo de actividad, actualicé nuevamente para ver qué era nuevo y, con suerte, mejorado. Para resumir: no tanto.

Ahora con paquetes de canela de núcleo 4.0.7, y el lanzamiento con renderizado de software como antes fue abismal con parpadeos horribles y problemas de actualización extraños alrededor de partes de las ventanas (es decir, los botones de minimizar / salir en particular). Al probar el modo de hardware, funciona sin eso, pero casi de inmediato comencé a tener un retraso de actualización a los pocos días de uso que está creciendo constantemente como lo hizo antes con el modo de hardware que me llevó a usar el software. El software parece un caso perdido en 4.0 hasta ahora, pero el renderizado por hardware todavía tiene este problema desde hace años.

¿Qué se necesita para solucionar este problema? Las resoluciones no se están reduciendo en las pantallas, y estos compositores parecen no poder manejar nada más allá de las antiguas resoluciones HD.

@mikebutash El modo de renderizado del software nunca fue diseñado para usarse mientras el controlador de gráficos está cargado. Es para el modo VGA.

Hay una variedad de RP abiertos para 4.2. Si se siente cómodo probándolos, puede consultar mis sucursales de relaciones públicas en el repositorio de Muffin. La otra opción sería deshabilitar vsync en Configuración -> General y habilitar la canalización de composición de fuerza en nvidia-settings. No se puede hacer nada más para solucionar este problema en la serie 4.0.x.

Editar: vea también esta página wiki .

@jaszhix , estuvo de acuerdo en que no pretende ser una solución, pero dice algo que funciona mejor que el método de hardware preferido, especialmente con el tiempo. Sin embargo, no tanto en la versión 4.0 más reciente, otra regresión con el parpadeo y el retraso extremo, e inmediatamente el retraso incremental ha comenzado nuevamente en el hardware. El hecho de que empeore con el tiempo muestra la inestabilidad del código, que se ha hecho desde principios de la 3.xy probablemente hasta la 4.2 todavía, así que dudo que importe en qué versión estoy.

Hice tanto vsync como la canalización forzada por recomendación anteriormente, pero noté la comprobación en este momento de que la canalización de composición completa forzada se deshabilitó nuevamente en la configuración de nvidia, por lo que la volví a habilitar y veré cómo funciona. Todavía veo un retraso ocasional después de habilitarlo en todas las pantallas, aunque queda por ver si empeora constantemente como tiende a hacerlo.

Si todos los DE están tan empeñados en la composición, sería bueno si aseguraran la estabilidad a escala en la resolución, ya que todos sufren los mismos problemas en grandes resoluciones. Cinnamon en el mío actúa como una pérdida de memoria, antes de reiniciar / actualizar después de 90 días más o menos, vería que cinnamon-desktop usa comúnmente el 80-90% de una cpu en proceso, un hablante superior en htop (no parecía hilo bueno en el núcleo, ya que tengo otros 39 subprocesos que podría usar), y usé mucha memoria, unos 20-30 gb (algo que se puede decir que tiene 128 gb en este sistema). Es necesario que haya una forma de probar esto a escala, y parecería una especie de prueba de estrés tipo valgrid. Después de aproximadamente 90 días de uso aquí, la canela siempre está lista para aparecer, y eso está en el procesamiento de software. Por lo general, morirá dentro de una semana en hardware. KDE sufre casi lo mismo.

La mayoría de las personas no utilizan pantallas con una resolución de 11200x2160 con frecuencia, pero son solo pantallas 3x 4k, que se están volviendo más comunes y más baratas cada día, o se ajustan en consecuencia. En algún momento, el compostaje debe tener en cuenta resoluciones como esta, y mayores, con estabilidad a largo plazo, o encontrar un método de compromiso que se adapte mejor a las masas. Prefiero tener redibujos estables en mis ventanas que oscilar / transparencia a lo largo del tiempo. Si supiera qué está desestabilizando mi sistema, felizmente lo deshabilitaría.

¿Cuál es la versión de su controlador Nvidia? Si está usando 390 o 396, use 415.25 en Ubuntu PPA .

La resolución combinada de mis monitores es 8560x1440, y no veo ninguna desaceleración con Cinnamon a lo largo del tiempo en mis sucursales de relaciones públicas actualmente, en los pocos períodos que no reinicio Cinnamon para el desarrollo.

La canalización de composición de fuerza agrega algo de latencia. Por lo general, no recomiendo su uso, y si tiene problemas con el vsync de Cinnamon, asegúrese de que "Permitir voltear" esté habilitado en nvidia-settings y que "Sincronizar con vblank" esté deshabilitado. No utilice ninguna solución alternativa de controlador diseñada para 3.8 y versiones anteriores.

No tengo claro qué consideras retraso: ¿el cursor no está sincronizado con la ventana al arrastrar? ¿O latencia de entrada general de Windows? Esas cosas se ven afectadas por diferentes partes del código del compositor. https://github.com/linuxmint/muffin/pull/397 mejora ambos, y https://github.com/linuxmint/muffin/pull/392 mejora este último, que me hubiera gustado poner en 4.0, pero necesita más pruebas.

otra regresión con el parpadeo y el retraso extremo

Mantengamos estos problemas separados, ya hay un par de problemas relacionados con el parpadeo y no he observado que haya empeorado en 4.0. Por supuesto, debe arreglarse, pero es difícil arreglar algo que no se puede reproducir de manera confiable.

Entonces, desde mi última actualización, estoy en nvidia 415.25-4, así que dentro de sus expectativas.

Configuré permitir voltear (no hecho antes), sincronizar con vblank deshabilitado (hecho generalmente) y forzar la tubería de composición completa en cada pantalla (restablecer esta verificación de tiempo).

Lag, es como todo lo que hago. Si hago clic entre las ventanas, el redibujo da como resultado un cierto retraso, en la pantalla se detiene durante unos segundos a la vez mientras se congela en su lugar. He estado jugando a Overlord en Steam recientemente donde hace esto, bastante molesto durante la batalla. He aprendido a darme cuenta y adelantarme cuando ocurre. El uso del escritorio también da como resultado este bloqueo, escribir esto da como resultado varios retrasos / tartamudeos al hacer clic entre las ventanas y durante la escritura. Todo se detiene por uno o dos segundos durante la escritura o cualquier actividad del mouse o teclado al azar.

Arrastrar cosas tiende a exacerbar el problema, la mayoría de las cosas de la interfaz de usuario tienden a enojar y retrasar el escritorio, deteniendo las cosas visualmente por uno o dos segundos. Avanzando 90 días, esto da como resultado una pérdida de 5 segundos en todo lo que hace cuando decide golpear, que es cada pocos minutos y, a veces, menos.

Con respecto al parpadeo, he notado que esto sucede en todas las pantallas, ciertas áreas al azar, no siempre iguales, pero como una especie de área fantasma del pasado que comenzará a parpadear durante segundos a la vez y desaparecerá. Esto es en las 3 pantallas en 4k, un pequeño subconjunto de una a la vez.

Este es otro artefacto de renderizado en software que parece, pero extraño cuando lo hace. No he visto esto en la renderización de hardware, pero hice mucho con el software durante los últimos 90 días usándolo. Bastante malo bajo hardware sin cosas más raras en software.

Configuré permitir voltear (no hecho antes), sincronizar con vblank deshabilitado (hecho generalmente) y forzar la tubería de composición completa en cada pantalla (restablecer esta verificación de tiempo).

Básicamente, lo que estaba sugiriendo era volver a habilitar el vsync de muffin en Configuración -> General y deshabilitar la canalización de composición completa de fuerza. Experimentarás el mayor retraso si ambos están habilitados.

El parpadeo es definitivamente peor en el procesamiento de software y cuando se usan ciertas variables de entorno de Clutter que se usan cuando está activado. No he visto que esto ocurra al arrancar con el parámetro nomodeset , pero se producirá un parpadeo si se carga el controlador de Nvidia mientras Cinnamon usa la representación por software. Ver # 7985.

El comportamiento de "estancamiento" suena como si el hilo se bloqueara de forma intermitente, ¿está utilizando subprogramas / desklets / extensiones de terceros? Consulte con gsettings get org.cinnamon enabled-applets && gsettings get org.cinnamon enabled-desklets && gsettings get org.cinnamon enabled-extensions .

Lo entiendo, no estoy seguro de cuánto dolor es bajo arco tratar de ser honesto, o normalmente estoy deprimido. Tiendo a correr con sus lanzamientos, actualizando y rezando un poco para que el problema simplemente desaparezca. Sin embargo, no en las revisiones importantes ahora, 3.xa 4.0 ahora. Intento no desviarme mucho, me gano la vida con este sistema, que incluye varios vpns, máquinas virtuales y varios otros puntos de integración que hago con él.

No obtengo el parpadeo debajo del hardware, aunque el retraso aleatorio se inicia casi de inmediato. Ya está empeorando, puedo decirlo.

Sí, tuve que dejar de usar Cinnamon nuevamente, los retrasos de redibujado de la ventana me estaban matando después de solo unos días, obteniendo retrasos de hasta 5 segundos en cualquier actualización de ventana que estaba usando activamente. Intentar jugar con esto es imposible. Normalmente, volvería al renderizado de software, donde normalmente se necesitan meses para llegar a los mismos retrasos prolongados en las actualizaciones, pero el renderizado de software ahora en 4.0 es completamente inutilizable.

En un ritmo acelerado, KDE / Kwin sigue siendo una caja de cambios también, casi el mismo problema, pero simplemente nunca conseguiré que la ventana se actualice, teniendo que minimizar y volver a seleccionar la ventana para volver a dibujar con los cambios.

¿Por qué es realmente tan difícil de conseguir para los compositores de diferentes DE?

Verifiqué las extensiones de terceros, y no, todo lo que tenía eran extensiones de canela, y en su mayoría predeterminadas. Por lo general, cubría cairo-dock y lo usaba para cosas personalizadas.

He pasado una buena cantidad de tiempo viendo htop, iotop, nvtop y powertop, y otros tratando de descubrir por qué ocurre esto, pero nunca veo que nada en particular aparezca como un cerdo de recursos de ninguna manera, fuera de cinnamon-desktop sí mismo y xorg a lo largo del tiempo.

Aquí, por supuesto, es donde siempre se vuelve confuso, ¿cuánto se están portando mal xorg, los controladores nvidia o canela? No conozco ninguna buena forma de depurarlos internamente. Estoy de acuerdo si conoces una buena manera de observar los aspectos internos de esos problemas, particularmente la canela en sí, ya que definitivamente se convierte en un recurso acaparador con el tiempo.

Las aplicaciones están haciendo lo suyo, solo que la ventana no se vuelve a dibujar durante esos momentos de "retraso", así que estoy de acuerdo en que algo se está bloqueando, pero no puedo entender qué es.

Tuve que cambiar a kde porque el retraso estaba causando mucho dolor aquí para usarlo finalmente, pero kde no parece ningún campeón, así que estoy dispuesto a probar canela nuevamente. Mint es casi demasiado simple, no soporto mucho gnome3, particularmente la versión disfuncional de ubuntu, así que sigo volviendo a canela a pesar de los problemas. Realmente me encantaría ayudar a solucionarlos si es posible, ya que obviamente no soy el único en este hilo.

Tengo un poco de curiosidad por saber qué pasó con las otras personas que vieron esto ...

¿Por qué es realmente tan difícil de conseguir para los compositores de diferentes DE?

La optimización de la composición es difícil de hacer y requiere mucho ensayo y error. Simplemente no es una cosa fácil de trabajar.

todo lo que tenía eran extensiones de canela, y en su mayoría predeterminadas. Por lo general, cubría cairo-dock y lo usaba para cosas personalizadas.

¿Principalmente? ¿Qué extensiones están en uso? Ese es un detalle importante. Necesitamos información que pueda ayudar a reproducir el problema, no un muro de peroratas de texto sobre la composición. ¡Gracias!

Había un escritorio que parecía habilitado, bbcwx, un subprograma meteorológico, pero no vi ninguna señal de que estuviera presente o ejecutándose antes.

[ usuario @ host ~] $ gsettings obtienen subprogramas habilitados para org.cinnamon
[' panel1: left: 0: [email protected] : 0', ' panel1: left: 1: [email protected] : 1', ' panel1: left: 2: [email protected] : 2 ',' panel1: left: 3: [email protected] : 3 ',' panel1: right: 0: [email protected] : 4 ',' panel1: right: 1: [email protected] : 5 ',' panel1: right: 2: [email protected] : 6 ',' panel1: right: 3: [email protected] : 7 ',' panel1: right: 4: [email protected] : 8 ',' panel1: right: 5: [email protected] : 9 ',' panel1: right: 6: [email protected] : 10 ',' panel1: right: 7: [email protected] : 11 ' , ' panel1: right: 8: [email protected] : 12', ' panel1: right: 9: [email protected] : 13', ' panel1: right: 10: [email protected] : 14 ']
[ usuario @ host ~] $ gsettings obtienen org.cinnamon enabled-desklets
[' [email protected] : 1: 50: 50']
[ usuario @ host ~] $ gsettings obtienen org.cinnamon enabled-extensions @ como []

Me doy cuenta de que lidiar con la composición es un trabajo complejo, así que no pretendo restarle importancia al esfuerzo, y ciertamente los aprecio en el fondo, pero la composición es en cada DE. Uso el eslabón más débil en todo lo que hay bajo Linux. Incluso en Windoze, Aero puede ser un estuche para la composición que encontré en mi uso limitado de la caja en una computadora portátil Dell. Es asombroso cuántos esfuerzos únicos parecen hacer esto mal, así que me pregunto por qué esto es tan necesario cuando parece imposible de lograr lo suficientemente bien. Parece que debería haber una forma mejor.

Ah, está bien, entonces si bbcwx está habilitado pero no se está procesando, entonces puede estar funcionando mal. También hay algunos PR que abrí destinados a 4.0.x que podrían estar afectando el rendimiento, como # 8180. No estoy seguro de cuándo se fusionará ese, pero todos deberían usarlo o cambiar a GWL.

Entiendo la frustración, es por eso que comencé a aprender C para poder mejorar el muffin, pero no hay mucho que pueda hacer excepto PR abiertas (que he estado haciendo). Los gráficos en Linux en general se han retrasado durante mucho tiempo, y recientemente comenzaron a ponerse al día después de algunos cambios importantes (por ejemplo, protón). Hay mucho trabajo por hacer y mi objetivo es hacer que muffin responda tan bien como DWM en Windows 10.

Ni siquiera recuerdo haberlo habilitado, por lo que debe haber sido algo aleatorio y olvidado. Lo quitaré, si puedo averiguar cómo.

He estado usando Linux desde 2006 a tiempo completo, y recuerdo antes / después de la composición, y la vida era mucho más simple antes. Lidé con problemas de Ubuntu y Compiz durante años, cuando eso comenzó, me llevó a KDE, luego a Mate / Cinnamon, y ahora de ida y vuelta últimamente, lo que apesta menos.

Hasta ahora, pasar de 3.xa 4.0 era lo peor con Cinnamon, pero kwin, compiz, murmura, todos parecen sufrir una fuga de recursos inherente que empeora con el tiempo. Como todos lo hacen, a menudo sospecho que es un componente de nivel inferior, como el controlador xorg o nvidia, el que está causando la desestabilización entre todos los DE, pero en realidad no hay forma de saberlo. Por lo tanto, empiezo con el DE, pero también veo varios * top's para tratar de averiguar qué está causando estos retrasos gráficos, hasta ahora sin éxito.

Tiendo a seguir las actualizaciones de pacman arch normal para intentar sacar actualizaciones fuera de eso limpiamente, no estoy seguro de cómo intentar los próximos lanzamientos de muffins en arch o lo haría.

También tengo este problema. Ver captura de pantalla para ver mis especificaciones. Incluso tengo 128 GB de RAM: https://gyazo.com/1f0443df15097949a2314bebba6d12db

Resolvió mi mudanza a XFCE> <(por lo que no se resuelve en Cinnamon)

@zenfulcoder ¿Para

@ danger89 yah Me encanta XFCE, acabo de cambiar a Cinnamon después de años de XFCE. Me gustó Cinnamon para el escritorio moderno y sus integraciones. Apesta que requiera OpenGL para ejecutarse.

Bueno, mi placa lo soportó, así que lo puse en XD. Pero así, por trabajo, nunca me quedo sin. Básicamente ilimitado. ¡Pero todavía va lento en Cinnamon!

@zenfulcoder Bienvenido a donde está el cuello de botella. No es debido al tamaño de la memoria, aún así podría ser la velocidad / latencia de la memoria y lo que sea. Y el resto de la PC (discos / placa base / hm .. etc.).

Sin embargo, es probable que no esté relacionado con sus especificaciones en absoluto, como puede ver en la sección anterior. Hay algún error en los controladores de video, Xorg o algo en esa área.

@ danger89 definitivamente es un problema con Cinnamon. Leí que la v4 podría ser mejor, pero aún no es lo suficientemente estable para Debian.