Nesta seção, as principais tecnologias empregadas no desenvolvimento deste trabalho de dissertação serão apresentadas. A escolha dessas tecnologias se deu de forma a possibilitar um desenvolvimento multiplataforma utilizando HTML5, embora o modelo de encapsu- lamento proposto, descrito na seção 3.1, esteja apto a ser integrado em outros ambientes de desenvolvimento.
2.3.1 WebGL
A ampla utilização do HTML5 trouxe diversas vantagens para os desenvolvedores e, indiretamente, para todos os usuários finais. Recursos multimídia, que antes dependiam de um plug-in ou mesmo de uma aplicação à parte, hoje possuem elementos próprios para áudio, vídeo e tela (canvas). Em particular, o elemento canvas é um padrão que define uma API (Application Programming Interface) gráfica de modo imediato [Levkowitz e Kelleher 2012]. Esse elemento permite que desenvolvedores manipulem imagens 2D e até animações, utilizando apenas HTML e JavaScript. A marcação HTML define um DOM (Document Object Model) que pode ser acessado e manipulado dinamicamente por um código JavaScrit. O código 2.1 é um exemplo simples do traço de uma reta, mas nele é possível observar a instanciação básica para a utilização do canvas.
Código 2.1: Canvas 2D 1 <canvas id="myCanvas" width="100" height="100" > </canvas> 2 <script>
3 var canvas = document.getElementById("myCanvas"); 4 var ctx = canvas.getContext("2d");
5 ctx.moveTo(0,0); 6 ctx.lineTo(100,100); 7 ctx.stroke(); 8 </script>
No entanto, é o uso do canvas em um outro contexto que traz um dos maiores avanços no HTML5: o WebGL. A utilização do canvas para o WebGL é simples e pode ser vista no código 2.2. O WebGL é um padrão na web, multiplataforma e isento de royalties, de uma API de baixo nível para gráficos 3D baseado no OpenGL ES 2.0 [Marrin 2011]. O OpenGL ES (Embedded Systems) 2.0 é uma adaptação da API do OpenGL voltada
2.3 TECNOLOGIAS 17 para aparelhos com poder de processamento inferior, como celulares ou tablets [Evans et al. 2014]. Desenvolvido pelo Khronos Group, a mesma organização responsável pelo OpenGL, o WebGL se consolidou através do WebGL Working Group - grupo formado pela Apple, Google, Mozilla e Opera. Desta forma, atualmente todos os principais browsers dão suporte ao WebGL. Assim, uma das maiores vantagens do WebGL é a sua capacidade de se integrar naturalmente a outros conteúdos web.
Código 2.2: Canvas WebGL 1 <canvas id="myCanvas" width="100" height="100" > </canvas>
2 <script>
3 var canvas = document.getElementById("myCanvas");
4 // Caso haja algum problema com o contexto padrão, o experimental é utilizado. 5 var ctx = canvas.getContext("webgl") || canvas.getContext("experimental-webgl"); 6 //Criar shaders...
7 //Criar buffers... 8 //Inicializar shaders... 9 //Renderizar...
10 </script>
Por permitir que desenvolvedores utilizem o potencial de renderização e processamento paralelo, as operações de renderização do OpenGL ES, e consequentemente do WebGL, costumam definir um array de vértices na CPU (Central Processing Unit) para posterior processamento na GPU. O uso da API pura do WebGL, analogamente ao OpenGL, permite que haja um controle profundo do processo de renderização e, consequentemente, exige mais do desenvolvedor tanto no processo de aprendizagem quanto na codificação. O WebGL segue o mesmo pipeline do OpenGL ES, sendo baseado em shaders, figura 2.10. Desta forma, é mandatório que o desenvolvedor faça uso de shaders próprios para controle dos vértices e fragmentos. Os shaders utilizados são definidos em GLSL (OpenGL Shading Language), uma linguaguem de alto nível. Com relação a variáveis, existem basicamente três tipos de declarações principais envolvidos no uso de shaders:
• Uniform: contém valores constantes durante toda a renderização do frame. Um uniform é enviando tanto para o vertex shader quanto para o fragment shader e é a maneira utilizada para se comunicar com os shaders.
• Attribute: contém valores específicos para cada vértice, não é global. Só está dis- ponível no vertex shader.
• Varying: atua como interface, exclusivamente, do vertex shader para o fragment shader, permitindo o compartilhamento de informações.
2.3.2 CoffeeScript
“A regra de ouro do CoffeeScript é: É apenas JavaScript.” , é assim que o CoffeeScript se apresenta em seu website [Ashkenas 2009]. Criado em 2009 por Jeremy Ashkenas, foi apenas em 2010 que o CoffeeScript atingiu sua primeira versão estável, e tem se
18 REVISÃO DA LITERATURA
(a) Processo de renderização WebGL
Figura 2.10: Pipeline de renderização WebGL.
popularizado grandemente desde então. O CoffeeScript é uma linguagem transcompilável para JavaScript, i.e., o código fonte em CoffeeScript serve como entrada para o seu compilador, que gera o código equivalente JavaScript como saída. Graças a isso, não há a necessidade de interpretação em tempo de execução. Inclusive, de acordo com [MacCaw 2012], o código gerado pelo compilador CoffeeScript, além de legível, tende a executar mais rápido do que um código equivalente em JavaScript escrito por uma pessoa. Ainda, é possível realizar o caminho inverso e converter códigos JavaScript para CoffeeScript através de projetos como o popular js2coffee, que realiza a transcompilação bidirecional [Cruz 2012].
Jeremy Ashkenas, em sua página oficial do GitHub [Ashkenas 2015], descreve o Cof- feeScript como Unfancy JavaScript, ou simplesmente “JavaScript descomplicado”. A sin- taxe do CoffeeScript herdou alguns dos recursos de linguagens que a inspiraram, como Ruby e Python [MacCaw 2012], e visa tanto a brevidade quanto a legibilidade do código. Focando em um código sucinto e conciso, o CoffeeScript utiliza, inclusive, espaços em branco significativos, como indentações, em sua sintaxe no lugar de parênteses e chaves desnecessárias. A otimização obtida é tal que ( [MacCaw 2012] chega a afirmar que) um código em CoffeeScript sofre uma redução de um terço a até metade do tamanho em relação a seu original em JavaScript.
Outro ponto importante, ao considerar a utilização do CoffeeScript, são as bibliote- cas. É possível utilizar qualquer biblioteca JavaScript em um projeto CoffeeScript sem problemas, ou mesmo bibliotecas CoffeeScript em um projeto JavaScript, isto pode sim- plificar bastante a integração com projetos já existentes [Ashkenas 2009]. As aplicações do CoffeeScript não se limitam ao navegador (web browser), como observa [MacCaw 2012], também é possível utilizá-lo em implementações server-side.
Entretanto, a adição de mais um compilador, entre o desenvolvedor e o JavaScript, não é a única desvantagem apresentada pelo CoffeeScript, como aponta [MacCaw 2012]. Quando comparado a linguagens mais estabelecidas, o CoffeeScript não apresenta uma comunidade tão grande. Porém, o número de adeptos tem apresentado um crescimento constante e, como prova de sua ampla utilização e integração, [MacCaw 2012] indica até mesmo o fato do CoffeeScript ter se tornado um padrão no Ruby on Rails 3.1.
Para novos desenvolvedores, o website oficial do CoffeeScript - [Ashkenas 2009] - apresenta uma ótima introdução. Lá, é possível executar alguns códigos demonstrativos
2.4 CONCLUSÃO 19