Conheça as principais novidades do GNOME 45 Alpha!

[Ariel_Bonfim]

Já temos disponível o GNOME 45 Alpha, com o qual, podemos ter uma boa ideia do que a nova versão da interface apresentará. A versão final deverá ficar pronta até o final de setembro, por enquanto, a versão Alpha possui:

• Melhorias no desempenho do gravador de tela;
• Correções no compositor Mutter, aprimoramento da interação com telas sensíveis ao toque, além de refinamentos no Xorg e no Wayland;
• O Nautilus está com o sistema de pesquisa mais rápido, entre outras mudanças;
• O GNOME Tracker está com melhor desempenho;
• O aplicativo de chamada Voip possui alguns números de emergência para acesso rápido;
• O sistema de pesquisa do calendário está meis veloz;
• Diversos componentes foram movidos para versões mais recentes das APIs do Libadwaita e GTK.

Você pode saber mais sobre as novidades dessa edição do GNOME e ainda baixá-lo, acessando o anúncio oficial!

[Melk]

Sem triple buffering ainda?

[henriquead7]

Triple buffering não foi implementado, e provavelmente nunca será, conforme a maneira do Daniel van Vugt pois trazia regressões conhecidas que foram identificadas na revisão do código - e que não foram corrigidas com o tempo - mas o principal motivo era que conflitava com mudanças que já estavam planejadas ao GNOME Shell.

Por exemplo os planos do Jonas Adahl que introduziu uma thread KMS, modifiers etc.

A sugestão de triple buffering da Canonical é uma solução a curto prazo, mas não implementada da maneira “correta/sofisticada”, e basicamente vai contra um dos princípios básicos do GNOME.

As melhorias estão chegando com um caminho mais sofisticado no uso do KMS atomic, modifiers e KMS thread etc. Fazer do modo “correto” é mais trabalhoso e raramente imediatista, mas acaba sendo uma base sólida e alicerce para o longo prazo.

Então espere novidades ao tema nos próximos lançamentos, mas não a implementação do triple buffering conforme a forma do Daniel.

[romulopb]

Eu acho meio que uma pena… Meio que o ótimo virou inimigo do bom neste caso… Mas pelo menos existem patches e distros com a funcionalidade para o pessoal escolher. Vamos torcer para não demorar anos para resolver pelo outro caminho.

[Melk]

Acho isso uma pena e acho que o Gnome está perdendo muito sem o triple buffering. A melhora no desempenho que eu sinto com o triple buffering é muito perceptível.

[henriquead7]

Uma pena fazer da forma correta? Já vejo isso completamente o oposto. Atalhos são bons para planos em curto prazo e que afete o mínimo possível, um projeto tão grande assim tem que pensar com uma visão mais ampla.

Além disso vários problemas foram introduzidos com essa solução, bugs, mais uso de GPU (por consequência mais uso de bateria) entre outros contras que impossibilitaria a implementação das coisas da forma correta. Resumindo… Seria escolher um atalho que impossibilitaria a implementação certa. E convenhamos fazer algo “errado” para depois desfazer tudo e fazer da forma correta não parece nada inteligente (e nem eficiente com tão pouca mão de obra).

Basicamente você pode pegar o atalho, ter vantagens momentâneas e diversos problemas sem solução ou fazer do modo certo e não ter esses problemas. Além de uma sólida base.

O GNOME escolhe não pegar atalhos. A vantagem que as coisas já estão ocorrendo da maneira certa, como a implementação do Jonas e muito mais chegando… Isso ao meu ver é uma grande vantagem e dá base para confiar nas implementações do GNOME. Ao curto prazo pode não ser o melhor, mas algo tão crucial como uma DE tem que ser confiável.

Lembrando que para o usuário final parece ser um escolha ruim esperar e implementar corretamente, visto que o usuário nem sempre sabe como estão ocorrendo as coisas por de baixo dos panos. Então é compreensível esse sentimento. Mas implementar algo tão crucial e descartar a forma correta de se fazer, que é o que a solução do Daniel basicamente faz - pois impossibilita a implementação do que já estava planejado e em desenvolvimento - é muito pior.

Seria como fazer a fundações de um apartamento de 20 andares com vigas de madeira, que impossibilitaria criar a fundação com vigas de concreto e aço, e ao curto prazo nenhum morador iria achar ruim, todo s ficariam super felizes com seu empreendimento novinho em folha - pois não saberiam da implementação errada - mas não se pagaria ao longo prazo, com prejuízos que ao decorrer do tempo iriam cobrar seu preço. E demolir o prédio para reconstruir, só por conta de um atalho, é uma má decisão (é basicamente essa a ideia).

[Melk]

Eu creio que o triple buffering da Canonical chegará ao upstream uma hora ou outra, inclusive o trabalho com o triple buffering no Gnome upstream não para.

Por que o triple buffering é necessário, segundo o Daniel van Vugt:

Não é um hack, é uma solução. É uma solução para um problema de agendamento de quadros que apenas o mutter possui, pois foi projetado de forma a impedir que a CPU e a GPU operem em paralelo. Além disso, para muitos drivers gráficos, só quando você utiliza a CPU/GPU nesse nível é que eles estão dispostos a aumentar suas frequências de clock para manter uma taxa de quadros suave.

A outra coisa que torna isso um problema específico do GNOME é o grande peso do JavaScript do gnome-shell combinado com muitas camadas de software entre ele e o OpenGL. Mutter também é um pouco culpado, pois tem o conceito de “alocar” e “pintar” separados. E alocar widgets muitas vezes acaba sendo tão demorado quanto a pintura/renderização, se não mais, e também só pode ser feito na CPU.

Então, em resumo: melhor paralelismo.

@henriquead7

Além disso vários problemas foram introduzidos com essa solução, bugs, mais uso de GPU (por consequência mais uso de bateria)

Bugs podem ser corrigidos.
Sobre o maior consumo de energia, Daniel van Vugt afirma o seguinte:

Eu respondi a isso algumas vezes ao longo dos anos, e a comunidade parece concordar, que aumentar o consumo de energia apenas quando for necessário atingir a taxa de quadros máxima é preferível a permanecer na metade da taxa de quadros.

Se você deseja uma taxa de quadros total com menor consumo de energia, adquira uma GPU diferente ou contribua para tornar o mutter/gnome-shell geralmente mais eficiente, como tenho feito há anos.

Todas as palavras do Daniel van Vugt que eu trouxe aqui foram tiradas do Gitlab, onde as pessoas parecem concordar com ele. Não é à toa que a comunidade do Gnome está esperando ansiosamente pelo triple buffering. E me corrija se eu estou errado, mas o Debian (muito famoso por sua estabilidade) contém o patch do triple buffering, não contém?

A implementação do triple buffering no Gnome tomou quase dois anos, então eu não a vejo como uma solução imediatista. O trabalho para melhorar o triple buffering não para, tanto é que meses atrás foram anunciadas melhorias que trariam menor latência de renderização e 10% de redução no uso de CPU durante o movimento do cursor do mouse.

[henriquead7]

Sim, mas isso do cursor de nada tem haver com a implementação do triple buffering do Daniel. Não disse que o recurso não é esperado ou que o GNOME não vai adotar. Pelo contrário, vem trabalhando para isso, mas de outras formas - que já estavam planejadas - e os problemas conflitam especificamente com as implementações planejadas por isso a implementação do Daniel não foi aceita (adicionar a implementação dele acarretaria em não implementar a forma já planejada).

A Canonical sabia, mas ao invés de alocar pessoal para seguir os planos de implementação do GNOME foi por outro caminho e sugeriu essa implementação do Daniel que quebrava a planejada pelos desenvolvedores do GNOME. Então sim, ela resolveu pegar um atalho ao invés de contribuir da forma já planejada, pois seria de imediato a sua implementação.

Palavras do Georges, desenvolvedor do GNOME, e um dos principais mantenedores do GNOME-Shell respondendo o tema no grupo do GNOME Brasil em (12/04/2022):

“Triple buffering não foi aplicado por 2 motivos: (1) tem regressões conhecidas e bem óbvias, que foram pegas na revisão de código mesmo, mas que não foram corrigidas; e (2) conflita com outras mudanças que já estavam planejadas”.

“Ela conflita com os planos do Jonas de introduzir uma thread para KMS, e conflita com algumas modificações minhas também, que não vou revelar por enquanto” .

De lá pra cá houveram diversas movimentações sobre o tema e correlacionados, alguns exemplos.

Garantir taxas de quadros constantes com clientes intensivos em GPU.

Adição de thread KMS.

Logo haverá implementação, mas não especificamente essa do Daniel van Vugt. Quanto ao Debian ou Ubuntu e demais distros, não é de hoje que elas implementam patchs no GNOME ou seus apps. Não é preciso existir alinhamento entre a forma de desenvolvimento entre projetos obrigatoriamente…

Se o Debian achou vantajoso implementar o patch com essa solução provisoriamente, com ciência dos riscos e vantagens, ok. Mas isso é totalmente diferente do upstream fazer o mesmo.

[Melk]

@henriquead7

Sim, mas isso do cursor de nada tem haver com a implementação do triple buffering do Daniel

Daniel van Vugt recently worked out another fix to the triple buffering code where now he’s seeing around a 10% reduction in the CPU usage during cursor movements. There are also lower latency by moving back from triple to double buffering sooner and is doing that task more reliably too. That’s in addition to the improvements from the dynamic triple buffering itself that have led to a much better experience in cases of integrated graphics, Raspberry Pi graphics, etc.

Fonte: Ubuntu 23.04 & Debian Prepare For Updated GNOME Triple Buffering Optimization - Phoronix

@henriquead7

A Canonical sabia, mas ao invés de alocar pessoal para seguir os planos de implementação do GNOME foi por outro caminho e sugeriu essa implementação do Daniel que quebrava a planejada pelos desenvolvedores do GNOME. Então sim, ela resolveu pegar um atalho ao invés de contribuir da forma já planejada, pois seria de imediato a sua implementação.

O triple buffering resolve problemas do Gnome, é um trabalho “pronto” e não há motivos para vê-lo como um hack/gambiarra. Tenho de concordar com o @romulopb: o ótimo está sendo trocado pelo bom.

[henriquead7]

Vamos lá, mas você entendeu que essa implementação ia contra as já planejadas? Que ela impossibilita as implementações que já estavam planejadas? (E com o tempo foram, e estão, sendo implementadas).

Imagina você criar e viabilizar todo um contexto e implementações que cauçem o caminho para a solução de uma implementação muito maior e complexa, e começar a trabalhar nisso.

Daí vem alguém, que ao invés de seguir todo o planejamento já em andamento, cria uma solução que resolva provisoriamente um dos problemas - que já estava em seu planejamento e sendo trabalhada para ser alcançado - e essa solução quebra todas as implementações já planejadas. Resolve o problema de forma imediata, mas impossibilita todo o resto que é a forma mais sofisticada de se fazer.

Você jogaria todo seu trabalho fora, que já estava fazendo, todo o planejamento de uma solução melhor, por algo que resolve - mas não dá forma mais correta/ e nem resolve tudo do planejamento, pelo contrário impossibilita essas implementações - e perderia todas as vantagens da implementação já planejada?

Além disso tudo, com esse alguém sabendo dos planos e tenso ciência que a forma planejada é superior - e que essa solução proposta, que joga por terra tudo - está sendo usada por resolver parte do problema de forma imediata, mas acabando com todo o resto.

Esse é o ponto. Não é largar algo por birra, ou apenas por não ser a melhor maneira, mas por quê vai inviabilizar todo planejamento que resolve muito mais coisas.

[henriquead7]

E houve um desencontro aqui, não estou falando disso do cursor (que tenha ganho 10% de performance, quanto a isso não tenho motivos para desacreditar). Estou falando da thread KMS dedicada ao cursor que foi algo implementado recentemente.

Só para contextualizar, para não ter mal entendimento. Não deixei translúcido o suficiente ao falar que de nada tinha haver. Estava falando disso e não do ganho do triple buffering. Espero que tenha dado para entender.

[Melk]

O merge request da thread KMS é de 8 meses atrás. O merge request do triple buffering é de 2 anos atrás…

[henriquead7]

Sim, mas estava no planejamento. Que é muito mais complexo e que resolve muito mais coisas. Triple buffering é apenas um dos problemas a serem resolvidos… Tem muita coisa que está a anos sendo desenvolvida e planejada, muito mais tempo que 2 anos, é isso que quero que entenda. Muito antes da sugestão do Daniel… Daí é só ler o que escrevi acima e vai compreender que a coisa não é tão simples como jogar tudo para os ares a fim de algo que resolve apenas uma coisa - e impossibilita as outras - exemplos dei aos montes… Além disso tem o próprio mantenedor do GNOME-Shell dizendo e falando os motivos.

[Melk]

Entendo. Vamos aguardar a chegada dessa thread KMS para ver se a espera valeu a pena.

[henriquead7]

É só a pontinha do iceberg… Tem muita coisa sendo desenvolvida e chegando ao Mutter, algumas escolhas parecem desconexas e fúteis, mas tem uma boa razão por trás. Apenas nem sempre é percebido pelo usuário final.

Uma escolha do GNOME vai além de mera estética, existe mais por trás | Cortes do Sextando

[romulopb]

Diversas outras plataformas mais energeticamente eficientes e com stack gráfico mais maduro implementam triple buffering, em alguns casos usam como default (iOS).

Eu pessoalmente acho que a solução final que a GNOME vislumbra não vai nunca resolver o mesmo problema que triple buffering resolve (se o objetivo for nunca implementar triple buffering), mas isso é apenas opinião minha.

Eu também acho que, inviabilizar é um termo muito forte, e poderia se ter conversado com a Canonical para demandar mudanças no patch para tornar a implementação mais isolável do código atual, isso é sempre possível.

Mas enfim… Como eu disse, vamos torcer para não demorar anos para resolver pelo outro caminho.

[henriquead7]

Boas notícias para quem estava esperando a implementação do triple buffering, após todos esses anos parece que as modificações no código renderam bons frutos e estão revisando para possível implementação no GNOME 47.

Ainda não é 100% certo, acho que 99.9% rsrsrs, mas a coisa parece ter ficado boa o suficiente para enfim ser mesclada.

Algo que até um tempo atrás não era possível, mas depois de resolver vários problemas enfim parece ter chegado o momento (lembrando que isso só está sendo possível graças a solução dos problemas que estavam em desenvolvimento anteriormente a esse patch e a melhora do código do Daniel, além é claro do Ubuntu e Debian).

Agora não sei quanto aos contras, como gasto energético que vi algumas pessoas relatarem após usarem o triple buffering, se foram solucionados ou mitigados.

Só pra deixar cristalino, translúcido como a mais pura água, para o entendimento: o patch inicial não se encaixava com o cronograma dos recursos em desenvolvimento, ele agora no estado atual parece que sim (códigos evoluem), também não perguntei para algum deve sobre os possíveis ajustes que tiveram/estão tendo que fazer para a implementação desse patch com o trabalho que estava em andamento - apenas especulando - mas creio que fizeram isso sim, caso contrário não estariam implementando.

Pois ouvi na época diretamente de um mantenedor do Mutter - até expliquei isso aqui também - que não era possível implementar o patch do Daniel naquele estado do código e que quebraria todo trabalho planejado e em andamento.

Se ele está sendo implementado é porque solucionaram isso.

[henriquead7]

É parece que não deu tempo de revisar e implementar tudo, provavelmente agora só entre no GNOME 48.