Olá pessoal,
Estou rodando um applet e notei que quando rodo no windows fica numa velocidade normal, responde legal. Agora quando testo o mesmo no linux parece que o estou rodando em um 286.
Por exemplo, tem um evento no applet de colisão do mouse com a imagem, no windows responde legal, agora no Linux, demora uns 5 segundos(no minimo) para a jvm responder que o mouse esta em cima da imagem.
Onde esta a portabilidade do java?? Alguem pode me dar uma luz?
Já tentou usar a Visual VM no Linux para ver o que está levando tanto tempo?
Usar a VisualVM deve ajudar. Além disso, que trecho de código é chamado quando o mouse encosta na imagem? O console do applet não mostra nenhum erro ou exceção? O programa foi rodado no mesmo browser nas duas plataformas, e usando a mesma versão do Java?
Opa, então, só agora que vi a msg.
Bom, eu descobri o que estava acontecendo logo depois. Na classe de controle, tinha a createBufferedStrategy(2). Reparei que o problema estava ai, e testei outros inteiros no linux, o que se encaixou melhor foi createBufferedStrategy(3) que gerou uma melhora surpriendente, o que antes levava de 5 ~ 10 segundos para responder, agora leva meio segundo no maximo. Ainda não esta respondendo na mesma velocidade do Windows, mas esta razoavel.
ViniGodoy:
Sim, vou pegar esse programa e testar e descobrir como funciona. Obrigado.
marcobiscaro2112
Então, não gera nenhum erro, o programa não trava, mas com o creatBufferedStrategy(2) ou qualquer int diferente de 3 e 4 a performance no linux reduz assustadoramente, parece realmente q esta rodando o programa em um 286, sem brincadeiras.
Como eu disse, bom, ainda não esta do jeito bom, leva certa de 0,5 segundos mais ou menos para a jvm responder quando deveria ser bem menos. Se alguem puder ajudar, enquanto isso eu vou tentando descobrir algo e baixar a VisualVm.
Vlw
Estranho… já rodei programas que usam BufferStrategy no Linux e funciona perfeitamente (somente com 2 buffers mesmo).
O Linux no qual testou está rodando a JVM da Sun ou a OpenJDK? E é a última versão? Detalhes como esses podem influenciar bastante.
Em que local você está criando o BufferStrategy? Geralmente essa criação deveria ser uma única vez, no momento da criação do seu JApplet.
Buffer tiplo raramente é necessário. Exceto em situações onde você vá fazer a pintura de multiplas cenas, usando vários processadores. Dificilmente você terá que passar mais do que 2 naquele parâmetro, mesmo no Linux.
ViniGodoy:
A classe é Control extends JPanel implements Runnable
e o createBufferedStrategy esta dentro do método run() e fora do while(running) (q esta contido no run()). Desculpa minha falta de conhecimento, eu não sei se o run() entra em loop mas sei o que while(running) parece que sim.
Outra coisa que notei agora é que quanto maior a imagem, mais demorado para obter retorno. O problema deve estar no metodo q fiz para colisão, que estou fazendo por rgb da imagem e não pelo tamanho da imagem. Acho que vou separar uma matriz com os valores do rbg da imagem ao invés de rodar a rotina “getRGB” para isso, e depois fazer a comparação.
Esta certo o createBufferedStrategy estar dentro do método run()?
Se está fora do while, está num bom lugar. Mas você só disparar esse runnable uma única, vez, certo?
Colisão por pixel é extremamente cara. O que eu geralmente recomendo é você fazer uma colisão por bounding box, que é rápida, mas pouco precisa. Quando o bounding box identificar colisão, aí sim, você usa detecção por pixel, apenas nos locais onde ela for detectada.
Se você tiver muitos objetos na cena, pode ser uma boa idéia particionar o espaço usando BSP Trees ou Quad Trees.