Cinnamon: Atraso de redesenho de janela ao arrastar janelas

Odeio dizer "eu também", mas ... "Eu também!" Estou executando em uma caixa um pouco mais antiga, com Cinnamon rodando em cima do Ubuntu 13.04. Todo o resto parece OK, é apenas o arrastar de janelas que é um problema. E a "gagueira" é perceptível, após a qual a janela pula para o próximo ponto. Parece acontecer ao arrastar qualquer janela (cromo, uxterm). Deixe-me saber quais outras informações de apoio posso fornecer. Não consigo encontrar nada de interessante nos registros do meu sistema.

Posso confirmar isso, mas tenho uma placa de vídeo muito ruim ...

Também estou tendo esses mesmos problemas. Estou executando o último Cinnamon do ppa noturno no Ubuntu 13.10.

Eu corro um sistema multihead no arch linux com cinnamon 2.0.2 atualmente (3x 1920x1080) eu tentei um 660 e meu 7870. Ambos exibem o mesmo comportamento, janelas extremamente lentas ao mover ou dimensionar. Estou usando os drivers de código aberto atm. (Tentará o catalisador assim que forem atualizados para funcionar)

No meu sistema é quase insuportável.

--- Atualizar --- se eu desabilitar no painel Configurações do Cinnamon -> Ladrilhos da Janela e Rebatimento de Borda -> Ladrilhos da Janela e Encaixe - as janelas se movem novamente rapidamente pela tela; Eu peguei essa dica movendo em torno de uma janela e peguei o novo HUD me mostrando a posição que eu poderia colocar aquela janela; sempre que o HUD estava aparecendo, o lagg iniciará.

Posso confirmar o mesmo comportamento no meu laptop; usando Manjaro Linux e Cinnamon 2.0.6
Eu tenho uma CPU P6100 dual-core e uma placa de vídeo Intel HD 3000.
Eu não tive esse problema antes com 1.6 ou 1.8.
Eu estava procurando uma opção com o Muffin para desabilitar o "conteúdo da janela" enquanto me movia, mas não tive sorte até agora, usando o editor Dconf.
Seria ótimo se alguém explicasse por que isso está acontecendo.
Mantenha o bom trabalho ;)!

O atraso para arrastar as janelas não é nada comparado ao redimensionamento de janelas (por exemplo: gnome-terminal), pode levar vários segundos :-(

Confirmo este bug com Intel core I5 ​​e controlador gráfico Intel (2ª geração).

Você pode definir o limite do HUD do ladrilho como 1 e isso basicamente desabilitará a exibição do HUD enquanto mantém o ladrilho habilitado. Talvez na próxima versão uma forma mais direta de desativá-lo possa ser adicionada, junto com um conjunto mais robusto de gráficos para animar o HUD.

Posso confirmar esse bug na CPU i7-2600K e GPU AMD R9 290 (drivers beta mais recentes). Particularmente na minha tela de 120 Hz. Desativar ladrilho e encaixe não ajudou.

Qual versão do Cinnamon você está usando? Uma das causas disso foi corrigida recentemente.

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

Estou executando o Cinnamon 2.0.14. Tentará instalar o mais recente.

Ter o último bolinho é provavelmente mais importante. Se você está no muffin 2.0.4, ainda não tem a correção. Se você executar 2.0.5, ele o terá.

(Não estou garantindo que seu problema específico seja corrigido, pode ser outra causa, mas vale a pena verificar)

Estou experimentando algo semelhante com o Cinnamon 2.0.14 e o Muffin 2.0.5 no Mint 16 com um i5-4440s com gráficos Intel HD 4600. Quando arrasto o Windows, eles não conseguem acompanhar o cursor do mouse. É como se as janelas estivessem presas ao meu cursor com um pequeno elástico.

Aqui está um vídeo do que estou experimentando. Este é um comportamento normal? http://youtu.be/KylzMTZpD7w

Posso confirmar que este caso ainda é válido para Cinnamon 2.2.14 e também Gnome Shell 3.12.2 no Debian Jessie.

Eu também entendo isso e é muito perturbador para ser honesto. Marcadamente menos suave do que o Unity etc e, na verdade, do Windows ...

Experimentando a mesma coisa que reclamei antes, mas também com uma NVidia GTX 760. O problema é definitivamente pior com vários monitores.

Eu recebo isso no Cinnamon 2.2.14, também, com um NVidia GT 630 com a versão do driver proprietário 340.24 (e dois monitores). Ao fazer o downgrade para a versão do driver 304, as janelas se movem rapidamente novamente, mas então sinto rasgo.

No domingo, 10 de agosto de 2014, 04:04:47 EEST, Andres Manz escreveu:

Eu recebo isso no Cinnamon 2.2.14, também, com um NVidia GT 630 com o
versão do driver proprietário 340.24 (e dois monitores). Ao fazer downgrade
para a versão 304 do driver, as janelas voltam a se mover rapidamente, mas então eu
experiência rasgando.

O atraso de arrasto da janela desaparece quando o vsync é desativado por
variáveis ​​ambientais. Driver AFAIK Nvidia 304 não habilita vsync por
padrão (ao contrário dos mais novos), então pode explicar porque você tem
arrastando e rasgando quando você faz o downgrade.

No entanto, o alto uso da CPU prevalece independentemente do vsync.

Posso confirmar que o Windows tem muito menos lag se eu não tentar habilitar o vsync (drivers intel), mas os vídeos não podem ser assistidos.

Também é estranho que o linux mint não tenha esse bug, e o arch linux tem.

@startas Não, estou pegando no Mint 17.

Ainda mais estranho desde que postei nesta edição, não tive o problema novamente. Desde então, instalei o cinnamon em várias configurações de dispositivos, hardware e software (distros) diferentes.

É estranho - eu "resolvi" esse problema (só tenho gráficos intel hd, então só pode funcionar para gráficos intel) recompilando xf86-video-intel com o sinalizador "--disable-dri3" e recompilando lib32-mesa com o mesmo sinalizador "--disable-dri3", é claro que você também deve remover o sinalizador "--enable-dri3".
Embora eu esteja usando o Linux de 64 bits, compilar o pacote mesa de 64 bits sem dri3 e instalá-lo trava o cinnamon desktop, mas de alguma forma recompilar apenas xf86-video-intel e a versão de 32 bits do mesa para sistemas de 64 bits "corrigiu este problema", também consertou enormes defasagens no cromo.
Apenas desabilitar o dri3 nos drivers 2d não funciona, mas desabilitar o dri3 na versão de 32 bits do mesa e instalá-lo funcionou, eu me pergunto por que - este pacote nem é instalado por padrão, já que o Linux de 64 bits usa canela de 64 bits, então ele usa 64 bits mesa, e não tenho ideia de como funcionava: D

exceto que há um problema com isso, DRI3 não existia quando este problema foi criado pela primeira vez.

Atualmente o Arch Linux também desabilita DRI3 por padrão, eu acho?

Este problema parece estar relacionado a algo que vejo no Kerbal Space Program no Linux (com Cinnamon): frameworks perfeitos, exceto quando eu clico e seguro o mouse para mover um foguete - então ele gagueja e salta feio. O Cinnamon está fazendo algum tipo de bloqueio no loop de redesenho de eventos do mouse?

No arch linux, xf86-video-intel é compilado sem dri3, mas mesa é compilado com dri3.

no meu pc bastante rápido, redimensionar janelas com canela é uma dor e eu adoraria uma opção para desativar a visualização em tempo real do conteúdo da janela. O xfce faz isso de uma maneira muito boa.

Isso está acontecendo, mas apenas no meu monitor externo, em um Macbook ("final de 2014") com gráficos Intel. A janela também exibirá artefatos de rasgo, novamente apenas no monitor externo. O atraso não muda perceptivelmente se eu ativar "TearFree", mas corrige o lacrimejamento. Estou aumentando o display externo em 2x2 com o xrandr.

editar: Devo observar que algo como o glxgears não sofre redução da taxa de quadros se eu arrastá-lo naquela tela, na verdade ele estava reportando ~ 71 fps em um monitor de 60 Hz, apesar do movimento fazendo com que pareça <10 quadros por segundo. Deixando-o sozinho, ele funciona normalmente.

edit2: parece que a escala também não altera o lag.

@wrouesnel e outros ...

O problema KSP, especificamente, provavelmente se deve ao fato de a taxa de pesquisa do mouse estar definida muito alta, principalmente se você tiver um mouse para jogos, como um Razer DeathAdder ou similar (que eu uso). O seguinte tutorial deve ajudar:

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

Gravei um vídeo mostrando o problema que tenho (problema de arrastar do navegador Chromium, enquanto o Nemo e o Firefox são executados apenas para comparação): https://youtu.be/Ec99EYjwiqY
Tenho o mesmo problema com o IntellJ e às vezes com o Pidgin ou menos vezes com o Nemo. Estou usando o Mint 17.3 e o Cinnamon 2.8.6 com drivers proprietários AMD. Coisas a serem observadas:

-Menta 17.3 com canela 2.8.6
-não conseguia carregar drivers GPU de código aberto para testá-los, isso me mantinha no modo de renderização de software agora (lembro que o código-fonte aberto do xorg funcionava bem quando instalei o 17.0 Mint alguns meses atrás)
-Forçar vsync desativado no amd propietary CCC ajuda a reduzir o atraso das janelas, mas torna o screen tearing especialmente ao rolar sites
-Quando o Cinnamon começou, tudo funciona bem, sem janelas lentas arrastando, sem redimensionamento lento. O problema está presente depois de algum tempo (por exemplo, 10-40 minutos após o Chromium ter sido iniciado)
- Reiniciar o Cinnamon (ctrl + alt + esc) ajuda temporariamente (ponto acima)
- (editar): isso não acontecia antes em 17.2 e Cinnamon 2.6 se bem me lembro, mas eu tinha um problema maior de rasgo naquela época.

Editar:
A mesma coisa acontece usando drivers de código aberto, consegui reinstalá-los.

Executando o Mint 17.3 Cinnamon fresco a partir de um stick USB, o mesmo problema explicado acima.
Verificado Ubuntu Gnome3 e Ubuntu Mate para comparação. Durante a execução de ambos a partir de USB por um longo tempo, não notei nenhum problema / lentidão.

De alguma forma parece que está relacionado a GPU, acontece principalmente com softwares que têm suporte a GPU, como o Chromium.
A segunda coisa a notar é que parece que isso acontece mais rápido ao ter intelihide para a barra de menu e continua a socar a barra de menu com janela do Chromium. Posso ouvir os ventiladores no laptop começarem a funcionar mais alto. Melhor arrastar a janela do Chromium circulando sobre a área de trabalho.

"Desativar composição para janelas em tela cheia" ativado / desativado - sem alteração

É lento para repruduzir mesmo com a barra de menus de soco, a maneira mais fácil é simplesmente navegar na Internet por algum tempo, mas eu entendo que pode ser um inferno para depurar.

Eu também tenho esse problema - mas o que percebi é que as janelas ficam _laggy_ depois de algum tempo - mas se eu abrir novas, elas não _lag_.

Por exemplo, se eu deixar um terminal ficar parado por, digamos, uma hora, ele irá gaguejar enquanto é arrastado um pouco, mas um terminal recém-aberto se comportará bem.

E sim, é quando eu tenho o cromo aberto (que está basicamente aberto o tempo todo).

Não é grande coisa, pois todos os outros aspectos parecem funcionar bem (por exemplo, você não percebe mais lag nos jogos ou algo assim) - a única outra coisa estranha que notei é que a tela de bloqueio leva cerca de 10 segundos. para carregar (nunca percebi isso antes de fazer upgrade para o Mint 17.3)

PS: Notei que o processo cinnamon --replace mostrará um uso de CPU bastante alto (cerca de 16% no meu sistema) algum tempo depois de mover uma janela _laggy_.

Intelihide desativado, ajuste o painel para sempre mostrar Executando o sistema operacional atualmente por algumas horas e surpresa! sem atrasos! Eu me sinto como se estivesse no céu.

Posso confirmar o lag da janela atrás do cursor, no Linux Mint 17.3, Cinnamon 2.8.6, com driver proprietário nvidia 352.63. Muito irritante! O problema é independente da composição habilitada ou não!

Também posso confirmar o atraso com Mint 17.3, Cinnamon 2.8.6 e Graphics integrado de i5-4210U ou nVidea GeForce 820M.
Brinquei um pouco com as configurações de mostrar / ocultar painel e parece que o lag só está lá quando o painel é mostrado. Quando eu configuro para ocultar automaticamente, todas as arrastagens da janela são suaves.
(Sim, eu sei que isso é o oposto do comentário de DarekDeo).

Talvez não seja o oposto completo, em ambos os comentários parece que algo está errado com o painel. :)

editar: ou pelo menos relacionado a ele.

Eu também tenho esse problema. Alguém tentou um driver gráfico diferente? Tive este problema no Xubuntu 15.10 e assim que mudei o driver, tudo funcionou bem. Não consigo encontrar essa opção aqui? Eu vou para os drivers no painel de configurações e uma lista em branco simplesmente aparece.

Configuração: drivers proprietários Fedora 23, Cinnamon, GDM, Nvidia (também com Nouveau)

Também estou tendo gagueira ao arrastar janelas e também ao digitar ou rolar um arquivo no Vim. Por exemplo, enquanto digito, algumas letras aparecerão com o pressionamento de tecla, então o cursor ficará pendurado por alguns milissegundos e, em seguida, as letras que digitei durante o bloqueio aparecerão.

A gagueira parece acontecer regularmente. Se eu tivesse que adivinhar, diria a cada 500 ms. Curiosamente, se eu mover uma janela rapidamente por um período de tempo, o topo mostra que o Xorg às vezes toma uma grande porcentagem da CPU (~ 53%) ao mover janelas ... isso não parece certo. Alguma ideia?

EDIT: Eu inicializei o Fedora 23 Cinnamon Spin Live CD e, curiosamente, não encontrei gagueira. Mas, usando o mesmo ambiente DM (drivers Cinnamon, lightdm, nouveau) na minha instalação de HDD ainda o faz. Posso tentar instalar o Cinnamon spin diretamente do Live CD em uma máquina diferente para ver se o problema persiste; Vou relatar de volta com quaisquer resultados.

Uau, tudo bem. Obrigado @DarekDeo, isso funciona muito melhor quando o painel inteligente está desativado. É uma pena que não posso assistir a vídeos do Youtube no grande player quando meu navegador está em tela cheia agora, e é por isso que eu liguei aquele painel em primeiro lugar, mas as janelas estavam ficando ruins.

Acho estranho como todas as janelas ainda estão lentas, elas não são insuportáveis, mas se eu voltar para o Windows, meus 144 Hz fazem tudo parecer e parecer tão suave, movendo as janelas e todas parecem tão sólidas e estáveis, volte O Linux e o meu 60 quase parecem mais suaves do que o meu 144 e as janelas parecem que devem ser lentas quando você os arrasta.

Eu também gostaria de acrescentar que o painel inteligente parece afetar as janelas também, meu navegador estava piscando muito branco com falhas, passei por alguns testes para ver qual deles não estava mais experimentando, pensei que algo poderia ser quebrado com canela ou meu driver gráfico, o painel era o problema @ _ @

Bem, isso é interessante, notei que a gagueira que eu estava vendo parecia acontecer na mesma frequência com que o miniaplicativo Monitor do Sistema estava atualizando, então eu o removi do painel e reiniciei, e agora a gagueira foi embora para mim. Isso parece apoiar ainda mais a sugestão de @DarekDeo de que algo pode estar errado com o painel. Talvez, qualquer processo / coisa que esteja atualizando, esteja interrompido brevemente durante o loop de redesenho (não sou um programador gráfico)?

Eu tenho o mesmo problema, na verdade, atualizar para uma versão mais recente do Cinnamon tornou-o um pouco melhor, mas meu desktop Nvidia (i5-3570k, Nvidia 780ti) ainda não é tão bom quanto meu laptop gráfico Intel muito menos poderoso (i7-4500u, Intel gráficos 4400).

Ambos estão executando o Mint 17.3, Cinnamon 3.04 (canal noturno) e o kernel 4.4.0-22.

Os drivers usados ​​são 364 (364.19-0ubuntu0 ~ gpu14.04.3) da Nvidia do PPA de drivers da Nvidia e os drivers Intel incluídos no kernel.

@davidva-cml obrigado, remover o miniaplicativo Sytem Monitor resolveu o problema para mim!

Desativado "sync to vblank" nas configurações do nvidia xserver e redimensionamento de aplicativos como o Telegram agora

Isso ainda é um problema para mim.
Estou usando uma nova instalação do Ubuntu 16.04.1, usando uma Nvidia GTX 1070 com driver versão 375, portanto, o desempenho não deve ser um problema.

@JosephMcc , podemos marcar esse problema como um bug?

@ davidva-cml Você conseguiu consertá-lo? Também vejo o Xorg além do uso da CPU ao arrastar janelas ... Talvez devêssemos relatar isso como um problema do Xorg. Embora possa sempre ser um problema do Canela, afinal ... A maneira mais simples de reproduzir é executar glxgears no plano de fundo enquanto arrasta as janelas.

No entanto, algumas pessoas com esse problema podem sofrer de um problema de lagg totalmente diferente (que pode estar relacionado ao Canela).

Receio ter o mesmo problema. Mas eu tenho um PC realmente poderoso (Core i7-5930K 3,5 GHz 6 núcleos + Nvidia TITAN X executando o driver nvidia mais recente + 32 GB de RAM e meu sistema operacional instalado em um SSD). Portanto, o desempenho não deve ser um problema. Mesmo assim, toda vez que tento arrastar uma janela, sinto lentidão como todo mundo neste tópico. Mas quanto mais aplicativos abertos eu tenho, mais lentidão fica!
Quando eu monitoro (htop), posso ver que o processo Xorg consome 90% ou mais do uso da CPU. Portanto, poderia vir de Xorg, não de canela diretamente.
Deve ser ótimo ter feedback para entender o que está acontecendo lá.
Obrigado.

Corrida :
Linux kernel 4.10.0-genérico
FerenOS (que está usando a versão mais recente da distribuição Linux Mint)
Canela corrente 3.4.6

Estou curioso para saber se outros descobriram alguma solução para isso recentemente, pois isso ficou silencioso.

Para mim, o Cinnamon começa a se desestabilizar com esse atraso crescendo desde a reinicialização ao longo do tempo, até que fica quase irritante demais para aguentar mais, e geralmente acho que tenho que reiniciar com força porque a tela não acorda mais do sono. Como na última postagem, é um computador poderoso (20 núcleos, 40 threads, dual xeon, 128 gb de RAM, nvidia 1070, dual nvme, monitores 3x 4k), então o desempenho não é um problema, e eu não consigo isso com outro desktop ambientes diferentes do kde (que tem seus próprios problemas de composição). Desativei o vblank e a maioria dos outros recursos gl, e ainda desestabiliza, geralmente dentro de uma semana, mas nunca quaisquer erros que revelem algo.

Estou usando os drivers Arch linux, Cinnamon 3.8.1-1, 4.16.13 e nvidia 396.24. Eu continuo atualizando esperando que isso vá embora, mas nunca vai.

Aparentemente (como acontece com quase todos os desktops agora), a resposta é simplesmente usar a renderização de software do desktop. Eu consegui ir algumas semanas da última vez antes de obter um tempo limite de exibição de 5 segundos a cada minuto ou mais, o que se torna bastante irritante com o tempo.

Normalmente eu apenas mudo para uma área de trabalho diferente, KDE (rezando para que eles corrijam também) ou Mate (marco tende a se comportar, mas a área de trabalho está faltando em comparação com outros) após um pacman -Syyu, mas desta vez eu notei a renderização do software canela modo. Depois de uma semana de uso normal com renderização de software, eu normalmente começaria a obter o atraso depois de alguns dias, mas com o modo de software, tem sido bom e realmente não vejo nenhuma desvantagem no desempenho no uso de desktop.

É uma pena que esse bug do compositor pareça persistir, mas quase certamente está relacionado a video / gl. Compositores são a ruína de todos os desktops linux que encontro, ainda não encontrei um que se comporte corretamente, mesmo o windoze aero que encontrei em 4k é uma porcaria absoluta que veio com meu xps 9560.

Uma boa solução é adicionar CLUTTER_VBLANK=none a / etc / environment e habilitar o pipeline de composição de força em todos os monitores em nvidia-settings em Display Configuration -> Advanced. Isso move o manuseio do vsync do compositor para o driver e ajuda no amdgpu também com TearFree habilitado na configuração do xorg.

Obrigado por isso, eu configurei no meu / etc / environment, mas não achei a necessidade de tentar a versão renderizada por hardware, pois parece apenas convidar drama e caos. Estou muito feliz com a versão renderizada por software até agora, alguns atrasos de desenho no cairo-dock e alguns outros aplicativos, mas não tão parecidos com a versão de hardware que faz cocô em si mesma.

Interessante, mesmo no modo de software agora, estou desenvolvendo o mesmo atraso, mas em uma taxa muito mais lenta do que com a renderização GPU completa. Parece algum tipo de vazamento de recursos, mas se não for a renderização direta contra o gpu, presumirei que haja algum bug no gerenciamento de recursos no desktop.

O que é um feedback útil, logs, depurações, etc. para ajudar a corrigir isso? Não vejo nada de anormal em qualquer lugar, exceto o desktop surtando em intervalos aleatórios / comuns.

Também para esclarecer, acho que muito disso tem a ver com as altas resoluções que uso. Minha área de trabalho funciona a 11520x2160 (3 monitores de 4k), o que sobrecarrega qualquer área de trabalho que eu acho que até tenta a aceleração GPU. Não acho que ninguém pense nesse tipo de coisa, mas com 4k, 5k e agora 8k chegando, a luta é real. É por isso que a composição parece falhar em qualquer área de trabalho, incluindo unidade, kde, canela ou até mesmo mate / marco com renderização direta contra gpu nesta escala.

É algo a se notar para os desenvolvedores, a escala de resolução para compor a renderização de maneira adequada tem sido um problema desde 2010, quando eu rodaria 6 telas de 1080p no linux com o advento da composição.

Portanto, estou de volta para verificar isso, depois de experimentar atrasos de 5 segundos no redesenho da janela na composição do software, mais recentemente, após cerca de 80 dias de tempo de atividade, atualizei novamente para ver o que havia de novo e, com sorte, melhorou. Resumindo: não tanto.

Agora em 4.0.7 pacotes centrais de canela, e lançar com renderização de software como antes foi péssimo, com tremulação horrível e problemas de atualização estranhos em torno de partes das janelas (ou seja, os botões minimizar / sair em particular). Tentando o modo de hardware, funciona sem isso, mas quase imediatamente comecei a ter um atraso de atualização dentro de alguns dias de uso que está crescendo continuamente como antes com o modo de hardware que me levou a usar o software. O software parece um desastre no 4.0 até agora, mas a renderização por hardware ainda tem esse problema há anos.

O que pode ser necessário para corrigir isso? As resoluções não estão ficando menores nos monitores, e esses compositores parecem não conseguir lidar com nada além das antigas resoluções HD ainda.

@mikebutash O modo de renderização do software nunca foi planejado para ser usado enquanto o driver gráfico é carregado. É para o modo VGA.

Há uma variedade de PRs aberta para 4.2. Se você se sentir confortável para testá-los, verifique minhas filiais de RP no repositório Muffin. A outra opção seria desativar o vsync em Configurações -> Geral e ativar o pipeline de composição de força nas configurações da nvidia. Não há mais nada que possa ser feito para corrigir isso na série 4.0.x.

Editar: Veja também esta página wiki .

@jaszhix , concordou que não é para ser uma solução, mas diz algo que funciona melhor do que o método de hardware preferido, especialmente com o tempo. Porém, não tanto no 4.0 mais recente, outra regressão com a oscilação e o lag extremo, e imediatamente o lag incremental começou novamente no hardware. O fato de piorar com o tempo mostra a instabilidade do código, o que acontece desde o início da 3.x, e provavelmente ainda na 4.2, então duvido que importe a versão que estou usando.

Eu tinha feito vsync e pipeline forçado por recomendação anterior, mas notei verificar agora que o pipeline de composição total forçado foi desativado novamente nas configurações da nvidia, então reative e verei como isso funciona. Eu ainda vejo um atraso ocasional depois de habilitá-lo em todos os monitores, mas ainda estou para ver como se fica cada vez pior conforme tende.

Se todos os DEs são tão empenhados na composição, seria bom se eles garantissem estabilidade em escala na resolução, já que todos eles sofrem os mesmos problemas em grandes resoluções. Cinnamon on mine atua como um vazamento de memória, antes de reiniciar / atualizar depois de 90 dias ou mais, eu veria o cinnamon-desktop comumente usando 80-90% de uma CPU em processo de alto-falante em htop (não parecia encadear bem no núcleo, pois tenho 39 outros threads que poderia usar), e usei muita memória, cerca de 20-30 gb (algo a ser dito tendo 128 gb neste sistema). Deve haver uma maneira de testar isso em escala, e parece que algum tipo de teste de estresse parecido com uma valgrid. Depois de mais ou menos 90 dias de uso aqui, a canela está sempre pronta para estourar, e isso está na renderização de software. Geralmente morre dentro de uma semana no hardware. O KDE sofre quase o mesmo.

A maioria das pessoas não usa telas com resolução de 11200x2160 normalmente, mas são apenas telas de 3x 4k, que estão se tornando mais comuns e mais baratas a cada dia, ou se ajustam de acordo. Em algum ponto, a compostagem precisa levar em conta resoluções como essa, e maiores, com estabilidade de longo prazo, ou descobrir um método de compromisso que se adapte melhor às massas. Em vez disso, tenho redesenho estável em minhas janelas do que oscilação / transparência com o tempo. Se eu soubesse o que estava desestabilizando meu sistema, ficaria feliz em desativá-lo.

Qual é a versão do seu driver Nvidia? Se você estiver usando 390 ou 396, use 415.25 no Ubuntu PPA .

A resolução combinada de meus monitores é 8560x1440, e não estou vendo nenhuma desaceleração com o Cinnamon ao longo do tempo em minhas filiais de relações públicas atualmente, nos poucos períodos em que não estou reiniciando o Cinnamon para desenvolvimento.

O pipeline de composição de força adiciona alguma latência. Eu geralmente não recomendo seu uso, e se você está tendo problemas com o vsync do Cinnamon, certifique-se de que "Permitir inversão" esteja habilitado nas configurações da nvidia e "Sincronizar com vblank" esteja desabilitado. Não use nenhuma solução alternativa de driver para 3.8 e anteriores.

Não está claro para mim o que você considera lag - é o cursor fora de sincronia com a janela ao arrastar? Ou latência de entrada geral de janelas? Essas coisas são afetadas por diferentes partes do código do compositor. https://github.com/linuxmint/muffin/pull/397 melhora ambos, e https://github.com/linuxmint/muffin/pull/392 melhora o último - que eu gostaria de ter no 4.0, mas precisa de mais testes.

outra regressão com a oscilação e atraso extremo

Vamos manter esses problemas separados. Já existem alguns problemas relacionados à cintilação, e eu não observei que seja pior no 4.0. Claro que precisa ser consertado, mas é difícil consertar algo que não pode ser reproduzido de maneira confiável.

Então, na minha última atualização, estou na nvidia 415.25-4, portanto, dentro das suas expectativas.

Eu defino permitir ligar (não feito antes), sincronizar para vblank desabilitado (feito geralmente), e forçar o pipeline de composição completo em cada exibição (reinicie a verificação desta vez).

Lag, é como tudo que eu faço. Se eu clicar entre as janelas, o redesenho resulta em algum atraso, na tela parando por alguns segundos por vez e congelada no lugar. Eu tenho jogado Overlord no Steam recentemente onde ele faz isso, de forma bastante irritante durante a batalha. Aprendi a perceber e antecipar quando isso ocorre. O uso da área de trabalho também resulta nessa paralisação, a digitação resulta em vários atrasos / interrupções de clique entre as janelas e durante a digitação. Tudo para por um ou dois segundos durante a digitação ou qualquer atividade do mouse ou teclado aleatoriamente.

Arrastar tende a exacerbar o problema, a maioria das coisas da interface do usuário tendem a irritar e atrasar a área de trabalho, paralisando as coisas visualmente por um ou dois segundos. Em 90 dias, isso resulta em uma paralisação de 5 segundos em tudo o que você faz quando ele decide acertar, o que ocorre a cada poucos minutos e às vezes menos.

Quanto à cintilação, notei isso acontecendo em todos os monitores, aleatoriamente em certas áreas, nem sempre iguais, mas como uma espécie de área fantasma do passado que começa a piscar por segundos de cada vez e vai embora. Isso ocorre em todos os 3 monitores em 4k, alguns pequenos subconjuntos de um de cada vez.

Este é outro artefato de renderização em software ao que parece, mas estranho quando parece. Eu não vi isso na renderização de hardware, mas fiz bastante com software nos últimos 90 dias ou mais usando isso. Ruim o suficiente em hardware sem coisas mais estranhas em software.

Eu defino permitir ligar (não feito antes), sincronizar para vblank desabilitado (feito geralmente), e forçar o pipeline de composição completo em cada exibição (reinicie a verificação desta vez).

Basicamente, o que eu estava sugerindo era reativar o vsync do muffin em Configurações -> Geral e desativar o pipeline de composição completa de força. Você terá mais lag se ambos estiverem habilitados.

A cintilação é definitivamente pior na renderização do software e ao usar certas variáveis ​​de ambiente do Clutter que são usadas quando está ativado. Eu não vi isso ocorrer ao inicializar com o parâmetro nomodeset , mas irá piscar se o driver da Nvidia for carregado enquanto o Cinnamon usa a renderização do software. Veja # 7985.

O comportamento de "travamento" soa como se o thread estivesse sendo bloqueado de forma intermitente. Você está usando miniaplicativos / desklets / extensões de terceiros? Verifique com gsettings get org.cinnamon enabled-applets && gsettings get org.cinnamon enabled-desklets && gsettings get org.cinnamon enabled-extensions .

Entendi, não tenho certeza do quanto é difícil tentar ser honesto, ou normalmente estou pra baixo. Costumo correr com seus lançamentos, atualizando e rezando um pouco para que o problema desapareça. Não em grandes revisões agora, 3.x para 4.0 agora. Tento não me desviar muito, vivo desse sistema, incluindo vários vpns, máquinas virtuais e vários outros pontos de integração que faço com ele.

Eu não entendo a cintilação no hardware, embora obtenha o lag aleatório quase imediatamente inicializando nele. Já está piorando, eu posso dizer.

Sim, eu tive que parar de usar o Cinnamon novamente, os atrasos de redesenho de janela estavam me matando depois de alguns dias, ficando até 5 segundos de atraso em qualquer atualização de janela que eu estivesse usando ativamente. Tentar brincar com isso é impossível. Normalmente, eu voltaria para a renderização de software, onde normalmente leva meses para obter os mesmos longos atrasos nas atualizações, mas a renderização de software agora no 4.0 é totalmente inutilizável.

Em uma batida para cima, o KDE / Kwin ainda é um estorvo, quase o mesmo problema, mas simplesmente nunca farei com que a janela seja atualizada, tendo que minimizar e selecionar novamente a janela para conseguir redesenhar com quaisquer alterações.

Por que isso é tão difícil para os compositores em diferentes DEs conseguirem?

Eu verifiquei as extensões de terceiros, e não, tudo que eu tinha eram extensões canela, e principalmente as padrão. Eu normalmente colocava o cairo-dock e usava para coisas personalizadas.

Passei uma boa quantidade de tempo assistindo htop, iotop, nvtop e powertop e outros tentando descobrir por que isso ocorre, mas nunca vi nada em particular aparecer como um recurso porco de qualquer forma, fora do canela-desktop próprio e xorg ao longo do tempo.

É claro que é aqui que sempre fica confuso, quanto o xorg, os drivers da nvidia ou o cinnamon estão se comportando mal? Não conheço nenhuma boa maneira de depurá-los internamente. Estou de ouvidos abertos se você conhece uma boa maneira de observar os problemas internos desses problemas, especialmente a própria canela, uma vez que definitivamente se torna um recurso consumidor com o tempo.

Os aplicativos estão fazendo seu trabalho, só que a janela não é redesenhada durante aqueles momentos de "atraso", então concordo que algo está sendo bloqueado, mas não consigo descobrir o que é.

Tive que mudar para o kde, pois o lag estava causando muita dor aqui para finalmente ser usado, mas o kde não está parecendo um campeão, então estou disposto a tentar a canela novamente. Mint é quase muito simples, não suporto muito o gnome3, particularmente a versão disfuncional do ubuntu, então continuo voltando ao canela apesar dos problemas. Eu realmente adoraria ajudar a consertá-los, se possível, pois obviamente não sou o único neste tópico.

Estou um pouco curioso para saber o que aconteceu com as outras pessoas vendo isso ...

Por que isso é tão difícil para os compositores em diferentes DEs conseguirem?

Otimizar a composição é difícil e requer muitas tentativas e erros. Simplesmente não é uma coisa fácil de trabalhar.

tudo o que eu tinha eram extensões de canela, e principalmente as padrão. Eu normalmente colocava o cairo-dock e usava para coisas personalizadas.

Na maioria das vezes? Quais extensões estão em uso? Esse é um detalhe importante. Precisamos de informações que possam ajudar a reproduzir o problema, e não de uma parede de discursos sobre a composição. Obrigado!

Havia um desklet que parecia ativado, bbcwx, um miniaplicativo de clima, mas não vi nenhum sinal dele presente ou funcionando antes.

[ user @ host ~] $ gsettings get org.cinnamon-enabled-applets
[' panel1: left: 0: [email protected] : 0', ' panel1: left: 1: [email protected] : 1', ' panel1: left: 2: [email protected] : 2 ',' painel1: esquerda: 3: [email protected] : 3 ',' painel1: direita: 0: notificaçõ[email protected] : 4 ',' painel1: direita: 1: usuá[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 ']
[ user @ host ~] $ gsettings obter desklets habilitados para org.cinnamon
[' [email protected] : 1: 50: 50']
[ user @ host ~] $ gsettings get org.cinnamon enabled-extensions @ as []

Eu percebo que lidar com a composição é um trabalho complexo, então não pretendo minimizar o esforço, e eu certamente os aprecio, mas a composição é em cada DE eu uso o elo mais fraco em tudo no Linux. Mesmo no Windoze, o Aero pode ser uma caixa de lixo para a composição que encontrei no meu uso limitado fora da caixa em um laptop Dell. É incrível como muitos esforços únicos parecem errar, então eu apenas questiono por que isso é tão necessário quando aparentemente impossível de realizar bem o suficiente. Parece que deveria haver uma maneira melhor.

Ah, ok, então se bbcwx está habilitado, mas não está renderizando, então pode estar funcionando mal. Também abri alguns PRs destinados ao 4.0.x que podem estar afetando o desempenho, como o # 8180. Não tenho certeza de quando esse está sendo mesclado, mas todos deveriam usá-lo ou mudar para GWL.

Eu entendo a frustração - é por isso que comecei a aprender C para poder melhorar o muffin, mas não há muito que eu possa fazer, exceto abrir PRs (o que tenho feito). Os gráficos no Linux em geral estão atrasados ​​há muito tempo e apenas recentemente começaram a recuperar o atraso após algumas grandes mudanças (por exemplo, próton). Há muito trabalho a ser feito e meu objetivo é tornar o muffin tão responsivo quanto o DWM no Windows 10.

Eu nem me lembro de habilitá-lo, então deve ter sido algo aleatório e esquecido. Vou removê-lo, se conseguir descobrir como.

Eu uso o Linux desde 2006 em tempo integral, e me lembro de antes / depois da composição, e a vida era muito mais simples antes. Eu lidei com problemas do Ubuntu e do Compiz por anos quando isso começou, me levou ao KDE, depois ao Mate / Canela, e agora vai e vem ultimamente, qualquer um que seja menos ruim.

Até agora, ir de 3.x para 4.0 foi o pior com o Cinnamon, mas kwin, compiz, murmure, todos eles parecem sofrer de algum vazamento de recursos inerente que só piora com o tempo. Como todos eles fazem isso, muitas vezes suspeito que seja um componente de nível inferior, como o driver xorg ou nvidia que está causando a desestabilização entre todos os DEs, mas realmente não há como saber. Portanto, eu começo com o DE, mas assisto também a vários * top's para tentar descobrir o que está causando esses atrasos gráficos, até agora sem sucesso.

Eu tendo a seguir as atualizações de pacman normais do arch para tentar puxar atualizações de fora de forma limpa, não tenho certeza de como tentar os próximos lançamentos de muffin no arch ou faria.

Eu também tenho esse problema. Veja a captura de tela para minhas especificações. Tenho até 128 GB de RAM: https://gyazo.com/1f0443df15097949a2314bebba6d12db

Resolvi minha mudança para XFCE> <(então não foi resolvido no Cinnamon)

@zenfulcoder Para onde h * K você usa 128 GB de RAM? Talvez seja hora de você mudar para o XFCE com certeza no seu caso .. haha

@ hazard89 yah, eu amo o XFCE, acabei de mudar para o Cinnamon depois de anos de XFCE. Eu gostei do Cinnamon para o desktop moderno e suas integrações. É uma merda exigir que o OpenGL seja executado.

Bem, minha placa suportou, então eu coloquei no XD. Mas assim, para trabalhar, nunca fico sem. Basicamente ilimitado. Mas ainda funciona lento no Cinnamon !!

@zenfulcoder Bem-vindo onde está o gargalo. Não é propriamente devido ao tamanho da memória, mas pode ser a velocidade / latência da memória e tudo o mais. E o resto do PC (discos / placa-mãe / hm .. etc.).

No entanto, provavelmente não está relacionado às suas especificações, como você pode ver na seção acima. Existe algum bug em qualquer um dos videodrivers, Xorg ou algo nessa área.

@ hazard89 é definitivamente um problema com o Cinnamon. Eu li que a v4 pode ser melhor, mas ainda não é estável o suficiente para o Debian.