Velocidade de repintura do Java 1.6 inconsistente - e o NetMeeting o corrige?

Question

Alguém viu um caso em que o desempenho gráfico de Java é terrível até você iniciar o NetMeeting? Simplesmente iniciar e sair do NetMeeting é suficiente para consertá-lo.

Estamos atualizando nosso JRE (para 1.6.0_12) em nossa empresa e notamos uma inconsistência ímpar. Uma pequena porcentagem de usuários notou que a velocidade de redesenho diminui muito, para onde leva vários segundos para repintar uma janela movida.

No entanto, tudo o que você precisa fazer é iniciar o NetMeeting e encerrá-lo. Isso corrige, pelo menos até você lançar um novo aplicativo Java, onde o lançamento do NetMeeting o corrige novamente.

Ainda não experimentamos algo como 1.6.0_14, pois ele quebra a certificação de suporte em alguns outros aplicativos e, portanto, não é uma solução geralmente aceitável. Além disso, não conseguimos discernir nenhum padrão entre as máquinas afetadas. É definitivamente baseado em máquina e não em usuário, já que todos os usuários que estão experimentando uma máquina "ruim" vêem o problema ...

    

Answer 1

Eu sei com certeza que o NetMeeting se conecta ao driver de vídeo, portanto, meu palpite é que o ato de executar o NetMeeting está alternando o driver para um modo que soluciona o problema de desempenho de gráficos Java. As máquinas ruins, por acaso, têm um adaptador de exibição diferente para os outros?

De qualquer forma, mesmo que não, com base nessa teoria, você pode obter alguns resultados de combinações de configurações no Painel de controle de exibição. Eu olharia para deixar uma má máquina de lado como um teste, reproduzisse o problema com as configurações padrão, desligasse todos os efeitos (assim como desativaria "mostrar o conteúdo da janela enquanto arrastava" e ajustaria a aceleração de hardware para "nenhum") gradualmente subir de lá até você acertar o jackpot.