Vscode-vibrancy: Problema ao arrastar, mover janela pela barra de título

Obrigado pelo feedback e sinto muito. Eu não sei como consertar isso. Eu acho que isso é um bug no Windows.

eu também passei por esse problema

O efeito acrílico terá um atraso de arrastar na janela do Electron. Se você usar desfoque por trás ou gradiente transparente, ele não aparecerá.

Na verdade, nunca vi tal problema no windows 10 1809.

Esse problema ocorre no Windows 1903 e não sei se só aparece nesta versão. (Na verdade, alguns erros de interface apareceram no Windows 1903.)

Eu só tentei isso no Windows 1903. Alguém já tentou essa extensão em versões mais recentes do Insider do Windows? Curiosamente, esse problema não parece afetar o uso da GPU ou CPU.

Também sou 1903 e enfrento esse problema

Mesmo problema em 1903

Mesmo problema

+1

Mesmo problema em 1903

Parece ser um problema de 1903, pois não tenho nenhum problema em 1809

+1

Em #14 v1.0.6. O atraso do mouse ainda existe, tentei muitos métodos e não consigo resolver o problema em 1903.

O problema não está no elétron, e atualmente não há uma maneira perfeita de abrir o efeito acrílico sem UWP em 1903.

O atraso do mouse ainda existe na versão mais recente do Windows 10 insider preview.

Obrigado por dedicar um tempo para analisar este @EYHN. Gostaria de saber se há uma maneira de enganar o Windows para pensar que o VSCode/Electron é um aplicativo UWP.

Só vim aqui relatar esse problema. Um pouco feliz por não ser o único a ter.

No meu pc no trabalho, especificações um tanto decentes, Windows 1809 - se move sem nenhum atraso.
No meu pc doméstico, especificações muito melhores, Windows 1903, com lag pra caramba.

Muitos dias se passaram e esse problema ainda está lá.
Eu empurrei o código nativo para Windows em https://github.com/EYHN/vscode-vibrancy/tree/master/src/blur-cli .
Talvez você possa me ajudar se você souber muito bem sobre o windows

notícias: Na janela 10 1903, descobri que reduzir a "taxa do mouse" abaixo da taxa de quadros pode efetivamente resolver esse problema.

Passei alguns dias pesquisando sobre esse problema, e agora desisto. Parece ser um problema dentro do DWM, a taxa de polling do mouse é maior que a taxa da tela, fazendo com que a solicitação de renderização seja bloqueada na fila e parece um atraso do mouse.

Não se preocupe, o mesmo problema também aparece no Microsoft Office, milhares de usuários do Windows estão preocupados com isso, a seguir estão algumas discussões:

https://answers.microsoft.com/en-us/msoffice/forum/all/why-does-my-excel-window-lag-so-much-when-moved/04b1fb97-b9da-481e-b37a-63257460c5b7

https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-mouse-lag-sluggish-window-dragging-in/12ab88a5-9e13-4d37-8f2d-106d56fcd775

Agora existem alguns métodos:

• Use o Windows 10 1809 e aguarde a Microsoft corrigir o problema
• Feche 'Mostrar o conteúdo da janela enquanto arrasta'
  Na caixa de pesquisa na barra de tarefas, digite 'desempenho' e selecione 'Ajustar a aparência e o desempenho do Windows' na lista de resultados. Na guia 'Efeitos visuais', desmarcando 'Mostrar conteúdo da janela ao arrastar'.

• Reduza a taxa de sondagem do mouse
  Em muitos painéis de driver de mouse para jogos, pode-se ajustar a taxa de polling do mouse.

  Também fornecerei uma versão apenas transparente, removendo o desfoque e a compatibilidade com todos os sistemas operacionais e ambientes.

我 花 了 好 几 天 这个 问题, 现在 我 放弃 了. 看来 是 DWM 内部 的 问题, 鼠标 回报率 高于 屏幕 刷新率 导致 渲染 请求 阻塞 在 队列 里 里 在 队列 里 像 像 像 延迟 一样 一样.

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

https://answers.microsoft.com/en-us/msoffice/forum/all/why-does-my-excel-window-lag-so-much-when-moved/04b1fb97-b9da-481e-b37a-63257460c5b7

https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-mouse-lag-sluggish-window-dragging-in/12ab88a5-9e13-4d37-8f2d-106d56fcd775

现在有几种备用方法：

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

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

@EYHN Acho que encontrei uma solução.
Em outro aplicativo de elétrons Terminus, eles fornecem uma configuração "tipo de plano de fundo" e dois tipos "Blur" e "Fluent", ele chama uma função this.electron.ipcRenderer.send('window-set-vibrancy', enable, type) , e descobri que "Fluent" funciona com atraso, mas "Blur" funciona bem. Não sei como this.electron.ipcRenderer.send('window-set-vibrancy', enable, type) funciona, mas acho que essa é uma solução antes que a MS o conserte no DWM.

Depois de instalar o Aero Glass , alterei o código do processamento do win10 para chamar o dwm (ou seja, a implementação do win7) e a janela não congelaria quando arrastada no win10 1909.

Depois que instalei o Aero Glass , quando alterei o código do processamento do win10 para chamar dwm (ou seja, a implementação do win7) parte da execução no win10 1909, a janela não congelava.

No entanto, o Aero Glass não funciona no win10 2004

Depois que instalei o Aero Glass , quando alterei o código do processamento do win10 para chamar dwm (ou seja, a implementação do win7) parte da execução no win10 1909, a janela não congelava.

No entanto, o Aero Glass não funciona no win10 2004

Pegar o arquivo do pacote de depuração do desenvolvimento geral do win10 e, em seguida, ordenar a reconstrução dos símbolos não funcionará?

Outra maneira é colocar o Windows no modo de economia de energia, que geralmente desativa todos os efeitos de transparência, mas por algum motivo corrige o atraso 🤷‍♂️

Parece que a versão KB4541738 do Win 10 2004 corrige esse problema.

Você pode fornecer uma solução detalhada, o windows1909 ainda tem atraso de arrastar

Estranho, eu costumava correr descompactado com arrasto normal sem demora, mas agora há um atraso ...

Parece que a versão KB4541738 do Win 10 2004 corrige esse problema.

😂linda

Você pode fornecer uma solução detalhada, o windows1909 ainda tem atraso de arrastar

O 1909 pode usar o Aero Glass diretamente? ps: O código de extensão precisa ser modificado

Como há um bug ao arrastar, ele pode ser resolvido fornecendo uma imagem de fundo transparente com efeito de vidro fosco?

Use EasyWindowDrag para mover a janela pode aliviar esse problema

Para mim, arrastar a janela ficou impossível com esta extensão instalada. A janela está se movendo em câmera lenta. Não é um problema de recurso de CPU/GPU.

Isso tornou o código VS inutilizável. Eu tive que desinstalar essa extensão para usar o código VS novamente.

@Spenhouet Obrigado por nos lembrar qual é esse bug. É um problema do Windows que vem como resultado do uso do efeito Acrílico de uma maneira tão sem suporte, e não há realmente boas soluções.

@ Toby56 Eu não tinha certeza se é o mesmo problema descrito pelo OP. Parece diferente do GIF que ele forneceu.

@Spenhouet Sim, o GIF não é muito claro, mas é como você descreveu! É um problema de sondagem do mouse, onde assim que você começa a arrastar, a janela fica mais lenta do que deveria e acumula um atraso enorme entre onde está e onde deveria estar. Infelizmente, não há nada que você possa fazer sobre isso :(

Então, isso ainda é um problema a partir dos últimos lançamentos do Win10? Não quero instalar isso se essencialmente quebrar o VSCode para mim ...

@iPyGuy Sim, basicamente, não espere que seja corrigido tão cedo. Não é um método oficial do Windows.

Parece que a versão KB4541738 do Win 10 2004 corrige esse problema.

Este patch não foi incorporado ao oficial de 2004 nem lançado no canal semestral.

@EYHN @Toby56
Você acha que isso poderia ser "consertado" desabilitando o efeito acrílico enquanto a janela é movida, como você (@Toby56) descreveu aqui: https://github.com/23phy/ewc/issues/22#issuecomment -599448590 ?

Como alternativa, você acha que seria possível desabilitar "Mostrar conteúdo da janela ao arrastar" nas configurações de desempenho apenas enquanto o VSCode estiver ativo/movido, alterando a entrada de registro relacionada em tempo real, em foco ou evento de movimento? Não ver o conteúdo da janela para todas as janelas é muito ruim, mas se isso afetasse apenas o VSCode, eu poderia viver com a compensação 😅

@jonaskuske
Desativar o efeito acrílico no arrasto provavelmente é a melhor solução interna. Pode ser um pouco complicado, mas você pode alterná-lo para apenas transparência sem qualquer desfoque. Outro fator que torna mais complicado, é que o acrílico quebra ao habilitá-lo a partir de outro efeito de desfoque no modo de economia de bateria porque o acrílico geralmente está desabilitado nesse modo? Eu não consigo me lembrar. Por causa disso, você precisa redefinir o desfoque a cada vez, o que pode criar um pequeno flash branco. Não há como saber se está no modo de economia de bateria ou não até onde eu sei e a economia de bateria não seria muito comum. eu não sei.

Mas funciona na maior parte e seria MUITO melhor do que mexer com o registro em tempo real. Com certeza eu não acho que fazer isso é prático.

@Toby56

o acrílico quebra ao ativá-lo a partir de outro efeito de desfoque no modo de economia de bateria porque o acrílico geralmente é desativado nesse modo?

Sim, o acrílico geralmente é desativado tanto no modo de economia de energia quanto enquanto uma janela não está focada. Portanto, geralmente há apenas uma janela com efeitos acrílicos ativos, enquanto as do fundo ficam opacas.

Não há como saber se está no modo de economia de bateria ou não até onde eu sei e a economia de bateria não seria muito comum. eu não sei.

Para mim, ele é ativado automaticamente quando chego a 20% da bateria, então não diria que é incomum. Mas você pode detectá-lo!
É possível com as ligações de nó para a API nativa do Windows Runtime :

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

let energySaverEnabled = PowerManager.energySaverStatus === 2

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

@jonaskuske
É ótimo que você conheça uma maneira de detectar o modo de economia de bateria usando ligações NodeJS para funções nativas do Windows! Isso parece uma maneira super simples de resolver alguns problemas. Desta forma, podemos escrever código que muda para "borrão atrás" normalmente, e para transparência simples no modo de economia de bateria, eliminando o flash branco desnecessário.

Para este problema específico, não sei como o código deste projeto está estruturado, terei que perguntar ao @EYHN se eles querem implementar algo assim. Talvez eu poste um GIF dele em ação.

@Toby56
Acabei de perceber que as dependências nativas provavelmente não são uma opção nas extensões do VSCode, portanto, embora essa solução deva ajudar todos que desejam adicionar o efeito acrílico ao seu próprio aplicativo Electron (para que possam compilá-lo em sua versão específica do Electron/Node), eu não sei se ajuda aqui :/

Provavelmente precisaria enviar um binário pré-construído separado em vez de usar as ligações do Node, como este repositório já está fazendo com blur-cli.exe 🤔

@jonaskuske
Isso é verdade! Não pensei nisso. Eu não tenho ideia de como, mas provavelmente poderia ser construído na parte C++ que é compilada no binário?? Eu realmente não conheço as limitações das extensões do VSCode.

Definitivamente útil para o meu próprio aplicativo 😀!

Certo, isso provavelmente deve funcionar. Infelizmente eu também não sei nada sobre C++ (além do pouco que é necessário para programar Arduinos) :/

De qualquer forma, se isso for implementado, definitivamente deve ser opcional, já que pessoas com monitores de 144Hz podem ter vibração durante o movimento da janela se definirem a taxa de amostragem do mouse para algo como 125, o que ainda deve ser rápido o suficiente para o uso diário.

@quank123wip @EYHN
Sim, também encontrei.
O fundo acrílico no terminal tem duas opções:

O Blur não tem problema, e o Fluent também tem problema de lag.

Então eu acho que essa é a resposta.

Não tenho certeza se isso é de alguma ajuda, mas o Window Terminal tem um efeito de transparência de trabalho. Eles chamam de "acrílico".
O Terminal não se baseia no elétron... ele é implementado em C++.

Você também pode alterar a opacidade:

Talvez olhar para a implementação deles possa ajudar:

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

@Spenhouet Sim, desculpe, mas isso não nos ajuda muito. O Windows Terminal de código aberto, bem como muitos outros aplicativos, usam esse efeito (sempre chamado de acrílico), mas são aplicativos dedicados do Windows e podem fazer a maneira "oficial", que funcionará imediatamente. No entanto, o que estamos fazendo é colocar algo onde realmente nunca foi planejado, e é por isso que tem bugs que não serão corrigidos

@Jinhaihan Sim, é verdade, podemos apenas desfocar assim, e não tem problema! Talvez nós devessemos. Mas não parece tão bom quanto o efeito acrílico "fluente". Acho que é um efeito antigo usado no Windows 7 (Aero), ou algo assim. O raio de desfoque não é tanto, e não tem a textura fluente de "acrílico" do Windows 10, assim como as outras camadas que fazem o desfoque acrílico parecer bom.

Ter uma opção como Terminus é perfeitamente possível, e talvez uma solução com a qual muitos ficariam felizes.

@ Toby56 Essa pode ser uma pergunta idiota: é impossível seguir o caminho "oficial"?

@Spenhouet Talvez, se você quiser reescrever o VS Code do zero. Caso contrário, provavelmente não.

Na verdade, não sei muito sobre como o efeito acrílico é aplicado a uma janela de cromo usando Node JS e C++. Mas o VS Code é e sempre será feito em Electron, e não há uma maneira oficialmente suportada de fazer isso. Estou muito espantado que este método funciona em tudo. Então, a menos que algum gênio encontre outra maneira, estamos presos assim.

@Toby56 Ok, faz sentido.

Acho que o efeito acrílico estará mais presente no Windows no futuro. O código VS provavelmente adotará isso em um futuro distante.

@Spenhouet
Sim, atualmente o efeito Acrílico é um recurso do XAML, a estrutura de interface do usuário que apenas aplicativos modernos do Windows (o tipo que você normalmente vê na Microsoft Store) podem usar. É por isso que não é problema para o Windows Terminal e outros. Aplicativos "old-school" podem usar a maioria das APIs modernas, mas não aquelas que dependem de renderização, visualizações etc.
Também não sei como funciona o hack nesse repositório, mas com certeza é um hack 😃

No entanto, com o próximo WinUI 3 (parte do Project Reunion , a tentativa da Microsoft de unificar APIs antigas e modernas), teremos um recurso chamado "Ilhas XAML", que permite o uso de UI moderna em aplicativos tradicionais. Então deve ser possível adicionar Acrílico sem hacks, talvez até como recurso direto do próprio Electron. 🙏🏻

@jonaskuske Uau que legal, não sabia que a Microsoft estava planejando algo assim!!! Algumas coisas, como ícones de bandeja, não são possíveis para aplicativos UWP sem empacotar um aplicativo Win32 complementar.

Tenho o prazer de informar que o Windows 10 Insider Preview (build 20161) corrigiu o problema para mim.

@LegoLivesMatter É fantástico ouvir isso! Eu deveria passar para o canal fast insider para verificar isso.

@Toby56 Boa sorte!

@jonaskuske @LegoLivesMatter @racoonx2p @EYHN

Posso confirmar que foi corrigido na compilação 20161!
Bem principalmente ...

Digo principalmente porque, embora seja ótimo e completamente utilizável agora, é um pouco peculiar. O redimensionamento ainda tem esse problema para mim, o que é irritante, mas provavelmente não é um problema para ninguém, a menos que você se encontre redimensionando muito. Redimensionamentos rápidos curtos são bons.

Rapaz, parece bom mesmo:

Eu tenho dois monitores e o mesmo problema também. Além disso, se a janela estiver próxima a uma borda de qualquer um dos monitores, uma pequena parte dessa borda ficará translúcida sem desfoque. Ainda melhor do que nada!

Também notei que quando a janela do VS Code é maximizada no monitor secundário, o desfoque desaparece, mas o "filtro" acrílico permanece lá. Pelo que posso dizer isso é uma consequência da janela "atingir" levemente o outro monitor. Isso não acontece quando a janela do VS Code não está focada ou quando está maximizada no monitor primário.

@LegoLivesMatter Sim, eu também tive esse problema, esqueci de mencionar. Tão estúpido, mas as janelas geralmente chegam ao próximo monitor, e essa é obviamente a causa. Cruze os dedos e talvez seja consertado. Esperançosamente, tanto o efeito quebrando quanto o cruzamento da janela!

Por algum motivo, usar um tema com o Stardock WindowBlinds também resolve esse problema. Deve estar fazendo algo com a composição do gerenciador de janelas, mas não faço ideia do quê. Há uma oscilação rápida ao maximizar a janela, mas, por outro lado, é bom.

Eu instalei o canal dev do windows-insider e o arrastar está bem. No entanto, o redimensionamento ainda apresenta problemas. Também notei que meu aplicativo winforms de 64 bits usando esse método tem esse problema, mas não a versão de 32 bits. Além disso, tenho um aplicativo de teste WPF que é de 32 e 64 bits ao usar SetWindowCompositionAttribute e redimensiona OK. Além disso, Avalonia redimensiona OK.

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

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

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

Obrigado pela sua resposta, mas afirmei que não tive problemas ao arrastar (ou seja, mover a janela) no canal insider-dev, mas tive problemas de redimensionamento no aplicativo de 64 bits.

Isso parece ter sido corrigido na versão do Windows que estou usando agora.
Eu descobri isso de repente, então não tenho certeza se é esta versão.

@doublethinkio Estou no Windows 10 build 19042.541 e ainda tenho o problema?

20H2 build 19042.572 aqui e também ainda acontece, então acho que algo que o @doublethinkio está indo especificamente fez com que funcionasse corretamente. Para mim, arrastar funciona e é suave, é muito, muito lento. Isso é diferente de algumas pessoas onde é lento e não suave.

@Jinhaihan mencionou que o Blur funciona para eles no Terminus e o Fluent tem o mesmo problema neste comentário . Eu fiz 5 minutos de pesquisa e parece que "Blur" mapeia para a opção 3, chamada ACCENT_ENABLE_BLURBEHIND neste projeto blur-cli e "Fluent" mapeia para a opção 4, chamada ACCENT_ENABLE_ACRYLIC em blur-cli . Isso não é configurável e, em vez disso, ACCENT_ENABLE_ACRYLIC (na verdade chamado ACCENT_ENABLE_ACRYLICBLURBEHIND na API) é sempre escolhido.

Tornar isso configurável seria bastante trivial, mas não tenho uma cadeia de ferramentas do Visual C++ configurada para poder criar um novo blur-cli.

Como deletar o efeito de vidro fosco, desinstalo o plugin e excluo a configuração.ainda inútil

@doublethinkio , obrigado por fornecer uma solução alternativa. Tentei executar EasyWindowDrag.ahk com autohotkey.exe . Infelizmente, recebo o erro abaixo. Não tenho problemas ao executar outros scripts AutoHotkey.

Mesmo se eu usar o script original que baixei diretamente de:
https://lexikos.github.io/v2/docs/scripts/EasyWindowDrag.ahk

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

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

; Easy Window Dragging -- KDE style (based on the v1 script by Jonny) 
; https://www.autohotkey.com
; This script makes it much easier to move or resize a window: 1) Hold down
; the ALT key and LEFT-click anywhere inside a window to drag it to a new
; location; 2) Hold down ALT and RIGHT-click-drag anywhere inside a window
; to easily resize it; 3) Press ALT twice, but before releasing it the second

Não tenho certeza se isso ajuda, mas aqui está um projeto que parece ajudar com o problema.
Seo-Rii/electron-acrylic-window

Descobri que definir o backgroud de Terminus ( eugeny/terminus 1.0.127) em Fluent, ele definirá o plano de fundo como não transparente ao arrastar a janela. Depois de parar ou ficar temporariamente, a janela restaura o fundo fluente. O atraso não aparecerá.

Talvez esta seja uma boa solução para o projeto.

A versão mais recente (v1.0.10) contém uma solução para o atraso do mouse, veja aqui para detalhes .

EDIT: Acabei de tentar a correção. É definitivamente mais rápido, mesmo em 60hz! Obrigado!!!