Por que os programas usam mais CPU com rotação de 90 graus na área de trabalho?

Question

Percebi que quando uso as ATI Tray Tools para girar minha tela em 90 graus (esquerda ou direita), o processamento da tela fica muito lento; O Firefox ou qualquer programa atrasa (usa 100% de um núcleo da CPU quando itens de menu são mostrados), e eu vejo uma taxa de atualização desagradável quando rodo páginas no firefox (parece que a tela é dividida em várias partes verticais e cada uma eles são reduzidos a ~ 30 pixels a mais que as peças anteriores à esquerda).

Se eu assistir a um vídeo (com o VLC) e clicar com o botão direito do mouse para configurações, a interface do usuário começará a ficar muito lenta. é difícil migrar para um item de menu diferente por causa disso, e o uso da CPU chega a 100% (para um núcleo) e, quando saio do menu, percebo que a descompactação de vídeo se tornou "corrompida", por isso preciso aguardar enquanto até que volte ao normal.

No Windows Media Player, a descompressão de vídeo é interrompida o tempo todo, por isso é impossível assistir a qualquer filme com ela (não que eu fizesse isso). Por outro lado, o Windows Media Player não fica lento quando eu vou para os menus do botão direito. Talvez o Firefox e o VLC usem a mesma biblioteca de renderização de menu, que de alguma forma está incomodando com essa rotação de 90 graus?

É possível corrigir esse atraso / excesso de uso da CPU, sem substituir minha tela ou GPU?

Tela: Samsung SyncMaster 226BW

GPU: ASUS EAH3450 (drivers mais recentes)

SO: Windows XP SP3 (não atualizado em um ano, e provavelmente não atualizará por medo de bloquear meu computador devido à cópia "ilegal" do Windows (que eu havia comprado (infelizmente))).

Alterar meu sistema operacional não é uma solução para mim. Eu já tentei o Windows 7 antes, mas reduzi a eficiência da minha GPU em torno de 20%. Eu já tenho uma GPU muito ruim, por que eu preciso de toda a velocidade que posso obter, por isso estou usando o Windows XP.

    

Answer 1

Acredito que isso se deva ao método draw, as origens de todo esse "fluxo de dados" e o desenho de uma tela foram desenhá-lo linha a linha na frente do visualizador muito rapidamente. (crt)
Os dados ainda estão sendo transferidos entre coisas no mesmo fluxo de dados linear que era antes.

_______________________________________line1

_______________________________________line2 (etc)

Está apenas sendo exibido agora em uma única atualização da tela. Quando você gira a coisa, tudo muda:

    _ <-- that goes | there   
and _     this goes |  here  
and _       on & on |   

Até que todos os dados sejam transmitidos linearmente para o dispositivo de exibição, totalmente reorganizados. É um trabalho muito diferente, vrses como as coisas foram originalmente projetadas.

Essa é uma explicação bem mansa, mas pode explicar rápido o suficiente.

Se ambas as peças de hardware foram projetadas para trabalhar no aspecto diferente da exibição "girada" (na verdade não girada), e o fluxo de dados não precisou ser todo re-configurado, então não há razão para que um "retrato "a exibição seria mais lenta. Apenas não é feito dessa maneira. É muito possível que exista um monitor que tenha apenas um aspecto diferente, onde seja mais alto e mais largo.

Se este processo de rotação for feito de forma muito melhor optomizada, funciona melhor com o hardware, ele deve ser capaz de ser feito sem destruir tudo.

Outra coisa que pode acontecer é renderização de sub-pixel (tipo claro) não funciona direito, por causa de como as 3 células de cor são dispostas horizontal e agora são giradas. Assim feito, tudo tem que ser mudado também. Pelo que entendi até agora não é.

Por falar em Renderizações, para as coisas que agem de forma diferente e para obter uma exibição com falha de um player de vídeo, altere o tipo de renderização. O tipo de renderização "overlay" apenas corta um buraco no software, então esse buraco é preenchido pelo hardware. A maioria dos players de vídeo, incluindo microsofts, tem uma configuração em algum lugar para alterar o tipo de renderização.