jump to navigation

Utilizando a biblioteca OpenGL(R) a partir de Java Março 24, 2007

Posted by pablo in Java, Terceiros.
2 comments

Introdução

 

O OpenGL(R) é um dos mais difundidos e populares sistemas gráficos para rendering de gráficos 2D e 3D. É amplamente utilizado em projetos de pesquisa para visualização em geral e também utilizado em muitos jogos. Aproximadamente 60% dos jogos para Playstation, por exemplo, são feitos em OpenGL. O mais conhecido exemplo de jogo para PC construido inteiramente em OpenGL é o Quake da Id Software.

OpenGL funciona como uma máquina de estados complexa, cuja manipulação é feita através de rotinas simples que são invocadas por funções da API OpenGL. Normalmente as rotinas são executadas inteiramente dentro do Hardware da placa gráfica, caso esta tenha suporte nativo – o que é extremamente comum hoje em dia. De fato, qualquer placa que comprada hoje possuirá suporte direto as rotinas do OpenGL.

Comumente, o OpenGL possui bind completo em C, mas caso se deseje utiliza-la a partir de Java(tm), será preciso utilizar algum mecanismo que permita acessar os Entry-points do bind da implementação em C a partir da Virtual-Machine Java.

A maneira de fazer isso em Java é através de JNI (Java Native Interface). Na realidade existem muitas bibliotecas java já prontas que fornecem meios para acessar OpenGL a partir de java, utilizando JNI, com um bom grau de abstração.

Primeiramente vou começar explicando alguns tipos de aplicações que são possíveis de serem desenvolvidas com o OpenGL. Em seguida vou listar algumas opções para poder utilizar OpenGL a partir de Java.

Em meus anos de experiência com esta biblioteca gráfica, tive a oportunidade de conhecer bem a fundo seu potencial e seu poder de trabalho. Hoje em dia, as placas estão se tornando cada vez mais eficiêntes, e a nova geração GeForce 8800 possui um pipeline de processamento genérico, com 256 pipes. Isso significa que a placa gráfica hoje é capaz de executar uam quantidade enorme de instruções simples em série de maneira muito mais eficiente que os processadores comuns da CPU (por este motivo as aplicações modernas já procuram distribuir processamento entre a CPU e a GPU – Graphical Processor Unit).

O OpenGL fornece uma maneira de explorar todo o potencial do hardware da placa gráfica sem precisar se preocupar com uma linguagem de baixo nível (como assembly), o que realmente pode ser facinante. Para se ter uma ideia, é possível com o poder do hardware gráfico comum de hoje em dia renderizar uma cena complexa (milhões de triângulos e vértices) em frações de milésimos de segundo, o que é absolutamente impossível utilizando-se somente a CPU (que não é especializada e já possui uma grande carga do S.O).

Alguns exemplo de aplicação gráfica com OpenGL:

  • Sistemas 3D para visualização de plataformas de petróleo em tempo real.
  • Sistemas para visualização de dados geosísmicos e geográficos
  • Jogos tridimensionais de alto desempenho
  • Aplicações CAD ou de modelagem
  • Grafos 3D ou Aplicações de Engenharia em geral

De uma forma geral, programar em OpenGL não é um problema somente de programação. Manipular OpenGL simplesmente requer conhecimentos sobre geometria e projeção tridimensional , bem como de sua arquitetura interna. Mas para quem tem experiência com bibliotecas gráficas, é simples migrar para o OpenGL.

À baixo listei e descrevi as duas melhores opções (na minha opinião) para se usar OpenGL em Java. A primeira, JOGL, é uma opçao para quem gosta de bibliotecas que usam o paradigma de orientação a eventos. A segunda, que na minha opinião é mais simples, é uma opção para quem gosta de uma biblioteca mais ao estilo de uso da biblioteca OpenGL em C.

Opções para uso do OpenGL em Java:

  • The JOGL Java/OpenGL binding: Funciona através de eventos (listeners/observers). Possui interfaces Java que tem assinaturas de eventos de fucionamento, tais como:
    • display: chamada sempre que a cena precisar ser desenhada na tela.
    • displayChanged: chamada quando ocorrer alguma mudança na tela.
    • init: chamada uma única vez no inicio para se ’setar’ configurações iniciais do estado do OpenGL ou da propria aplicação Java.
    • reshape: Sempre que a janela for maximizada, minimizada ou reposicionada.
  • Lightweight Java Game Library: É uma biblioteca mais leve e que não é orientada a eventos. Isso pode tornar as coisas mais simples para quem está acostumado a utilizar a biblioteca OpenGL em C ou C++.

Em ambos os links das bibliotecas listadas, existe uma boa documentação para inicio de uso. É claro que, existem algumas outras opções para se utilizar OpenGL de java, tal como o Java3D. No entanto estas opções não são tão bem documentadas e, especificamente o Java3D, não é simplesmente um binding para OpenGL, ele é todo um toolkit gráfico construído em cima do OpenGL, o que significa que ele tem um nível muito alto de abstração e possui grafo de cena e classes complexas. Ele pode ser uma boa opção para quem quer construir aplicações complexas ou jogos, pois certamente aplicações desse tipo requerem uma abstração em cima do OpenGL. Com as bibliotecas que eu citei, você mesmo pode construir uma outra biblioteca que abstrai de maneira particular as funcionalidades do OpenGL. Mas é claro que é preciso ter em mente que isso pode ser algo bem trabalhoso, então o Java3D pode ser uma boa opção em alguns casos.

Use a criatividade! Componentes Swing Janeiro 4, 2007

Posted by felipecruz in Java, Swing.
4 comments

Se alguém te pedisse para criar uma interface com uma tabela, mas a classe JTable não existisse, o que você faria?

Num post anterior, eu te disse que um comboBox era um textField, um botão e um listbox. Nesse exemplo eu quero mostrar uma tabela, que atende necessidades básicas (exibir dados em uma forma de grid e poder obte-los).

Veja o resultado:

Exemplo

Um painel, com N sub-paineis que representam linhas(e N o numero de linhas), todos com X numeros de elementos, (onde X é o numero de colunas). As células só podem ser editadas com o mouse sobre elas, mas nada impede de que um clique habilite a edição e outro clique desabilite a edição. Os valores são obtidos por um método “getValue(int row, int col)”.

codigo

Como eu escrevi esse post faz um tempo, vou colocar abaixo como essa tabelinha está atualmente:

versao nova

Eu quero mostrar com esse exemplo simples que criar componentes novos com swing não é um bicho de 7 cabeças e as vezes os problemas podem ter soluções mais simples do que imaginamos… o exemplo é pra abrir sua cabeça e é meramente ilustrativo!

Use a criatividade!!

GWT (Parte 1) – Visão Geral Janeiro 4, 2007

Posted by viniciusdiniz in GWT, Java, Web.
7 comments


GWT é uma ferramenta para construção de interfaces Web mais amigáveis e rápidas. Guarde isso… interface… essa é a proposta do GWT, pelo menos por enquanto.
Tenho trabalhado e utilizado o GWT em alguns projetos. Gostaria de passar algumas lições que já aprendi com esse produto que está tão em evidência no momento.

Vou começar destacando os principais pontos que todos deveriam saber para começar a utilizar o GWT.

       

       

        1.      Tudo que você codifica em java na parte cliente, vira javascript (Ver o tópico http://loogica.wordpress.com/2006/11/30/gwt-voce-entendeu/)

    

                Como tudo da parte cliente vira javascript, é muito bom você ter uma boa noção de javascript para não querer  usar Reflection, Serialização, etc na parte cliente. Pois qualquer pessoa que conheça javascprit pode ver que não se consegue ainda fazer essas coisas com essa linguagem.

       

       

        2.      GWT é para a parte da interface do seu sistema.

       

                O GWT foi feito para facilitar e agilizar o processo de desenvolvimento das interfaces de aplicações WEB utilizando AJAX. Não é uma boa prática embutir o código de lógica do negócio nas classes do lado cliente da aplicação. É muito comum as pessoas, utilizando GWT, colocarem toda a lógica da aplicação junto com a lógica de apresentação e só utilizarem o lado servidor para executar lógicas específicas de persistência.        

                Ex: Ter toda a lógica de validação, verificação de privilégios, relacionamentos nas classes do lado cliente e só chamarem uma função  insertUser(User u); no lado servidor. Que vai ter somente a persistência desse objeto User.        

                Meu comentário sobre do post http://loogica.wordpress.com/2006/11/30/gwt-voce-entendeu/ 

                “O que acontece com isso? Perda de escalabilidade. Se você quiser integrar sua aplicação com um ambiente desktop, mobile, etc etc você terá que reescrever toda a lógica de negócio e pior, se tiver que alterá-la, vai ter que repetir a alteração para todos os ambientes, pois o GWT não se aplica a outro ambiente sem ser Web.”.        

                O problema, na minha opinião, está em tudo ser Java. Todo o código são classes Java e os desenvolvedores perdem a referência do conceito MVC. Sempre fomos acostumados a fazer os famosos códigos HTML/Javascript que correspondiam a camada de apresentação da aplicação. Com isso nunca nos preocupamos com a separação desta.

       

       

        3.      Tente entender como o produto funciona e não como utilizá-lo.       

     

                É primordial entender como as coisas são feitas no produto. Como classes Java viram javascript e tem o mesmo comportamento no browser? Como é feita a comunicação cliente/servidor? Como em um evento javascript, é transformado em uma chamada ao servidor?

                Entendendo como o produto funciona, no final, você vai saber muito bem como utilizá-lo.

       

       

        4.      Utilização e leak de memória no browser.

       

                A evolução das aplicações web está acontecendo em uma velocidade que está difícil de acompanhar. Mas não há como negar que existe uma tendência muito grande de se fazer tudo web. Hoje em dia já existem várias aplicações web que são cópias de aplicações desktop.        

                O GWT foi no ponto certo. Pegou uma área ainda meio crua no mercado que é a utilização de ajax e a construção de interfaces mais amigáveis em HTML/Javascript. Junto com isso, existe a possibilidade de organização, reaproveitamento e toda uma organização de código que antes eram bem mais complicadas de se ter.        

                Finalmente, com interfaces cada vez mais poderosas e complexas, automaticamente aumentam o consumo de memória de quem exibe essa interface, que no caso é o browser. Como no GWT tudo vira JavaScript, é bom pensar em como é feita a utilização de memória desse código. Um exemplo básico de leak de memória em javascript utilizando o IE é explicado no link http://javascript.crockford.com/memory/leak.html . Quando criarem um painel e não forem reutilizá-lo, pensem se a memória que o mesmo utiliza está sendo desalocada.        

                Experimente abrir o Firefox e deixar por um ou dois dias uma aba com o GMail aberto para você ver qual será o consumo de memória do Firefox (válido para IE, Opera, etc).

       

       

Se algo estiver equivocado, incompleto, ou se quiserem complementar, fiquem a vontade para escrever.

Essa foi a primeira parte. Vou publicar mais alguns pontos, boas práticas, bibliotecas, etc sobre GWT.

Abraços!

SwingUtilities.. Dezembro 19, 2006

Posted by felipecruz in Java, Swing.
3 comments

Não esqueça, jamais, de atualizar componetes gráficos no EDT…. EventDispatchingThread!
Exemplo:


SwingUtilities.invokeAndWait( new Runnable() {
public void run() {
myTable.setModel(someTableModel);
myTable.updateUI();
}
});

http://meuOutroBlog/swing-event-dispatching-thread-edt.html

2006 para 2007… Dezembro 15, 2006

Posted by felipecruz in Java.
add a comment

As ferramentas e\ou frameworks que eu mais usei em 2006:

Projetos pessoais

No trabalho

Dia dia

Observações:

  • Eu não usei Hibernate em nenhum projeto profissional ou pessoal, mas vi *muito* projeto usando.
  • Adeus Struts

O que eu pretendo usar em 2007:

Metas para 2007

  • Continuar 3 projetos pessoais, um deles o pd4j, um projeto web e um desktop.

E você, o que mais usou em 2006 e o que pretende para 2007?

JDK GPL -> Melhores códigos Swing? Dezembro 14, 2006

Posted by felipecruz in Java.
4 comments

Você já parou pra pensar que um JComboBox é uma composição de um textfield, um botão(com uma seta para baixo) e uma listbox? Muita gente certamente não pensou nisso. Agora que o jdk terá os fontes abertos, você acha que através do estudo dos fontes(e possibilidade de modificação) a qualidade do código swing produzido será melhor?

Eu acho que sim. É difícil fazer um bom código swing sem conhecer bem a API e sem um bom livro do lado mostrando as melhores práticas. Por isso geralmente os códigos swing de quem está começando são ruins, ao passo que um iniciante programando usando webwork com hibernate, geralmente faz o que todos fazem exceto por alguns refinamentos que se descobre com o tempo.

Como o Rafael chamou a atenção, os fontes acompanham o JDK faz um tempo, mas agora eles serão liberados com a licensa GPL e não mais a SCSL(ate a primeira metade de 2007 http://www.sun.com/2006-1113/feature/story.jsp). Isso deixou o post um pouco confuso, então eu ajustei.

Isso acrescenta alguma coisa, você costuma abrir os fontes do JDK, alterar? Isso irá trazer algum benefício? é a pergunta reformulada!