Forjeando que es gerundio

La señorita Kidman me ha dicho que le gusta mucho Cabaret y que quería aparecer en una foto. Me he hecho el remolón pero al final me ha convencido
Hoy en Madrid es fiesta y ha sido un día productivo. Desde la última visita han aparecido unas cuantas características:

• El fondo de las transparencias cuenta, además de los degradados, con un bitmap. Ambos elementos se pueden superponer o usar uno para colorear el otro. En la foto de arriba se puede apreciar esto último: la señorita Kidman está en escala de grises, pero la foto se colorea con un degradado de rojos. Colorear una foto de Kidman con colores fríos debe ser pecado.
• El escalado de las texturas se hace mediante mipmaps, de forma que la calidad visual mejora considerablemente. Me ha sorprendido mucho lo bien que funcionan los mipmaps al agrandar una imagen: ¡los textos realmente no parecen escalados! Las imágenes no aparecen pixeladas ni nada de eso, una gozada.
• Ha aparecido una nueva ventana titulada ‘vista previa’ que muestra la colección de transparencias de la presentación (en la jerga del código de Cabaret, el conjunto de ‘escenas’ que hay en el ‘paquete’). Por ahora no es más que una vista previa, pero se usará para organizar las escenas (copiar, pegar, etc).

El otro día conseguí, por fin, subir cosas al repositorio de Subversion, más que nada para aprender porque hay que ver lo mal que se me dan estas cosas…. Conseguí localizar un cliente de SVN medianamente decente y la verdad es que tiene muy buena pinta. No me gusta mucho usar la terminal para estas cosas. En realidad trato de evitar la terminal… :$

El caso es que en mi cachito de forja.rediris.es hay un poco de código de Cabaret. Se puede leer y estudiar y, por supuesto, mejorar. Imagino que no hay acceso anónimo para escritura, pero de alguna forma se podrá solucionar, digo yo. Ya dije que de SVN no tengo mucha idea…

El escritorio de Cabaret

Los ánimos recibidos para atacar el proyecto (¡gracias chicos!) me han motivado para crear un pequeño toolkit. En este momento consta de:

• un escritorio (ni dos ni tres )
• ventanas
• sliders (esas barritas horizontales con los que cambias un valor numérico)
• etiquetas
• una barra de menu

El aspecto está a medio camino entre el pantallazo de Aperture y el escritorio de Gnome. Aun quedan muchas cosas por hacer, pero bueno, la prueba de concepto está ahí y se puede usar aunque, claro, por ahora sólo funcionan cuatro cosas…

Escogiendo toolkits

Una vez que tenemos el motor para…

1. Representar texturas en polígonos OpenGL
2. Renderizar fuentes TrueType en una textura OpenGL

… podemos continuar. El siguiente paso representa una difícil elección y es escoger un toolkit que nos ayude a crear una interfaz gráfica. Un poco de inspiración:

http://www.professional.co.at/Apple/Bilder/05/aperture/aperture_screen.jpg

(Debería salir una foto de Aperture, un software desgraciadamente cerrado y demasiado caro) Este pantallazo lo resume todo: no se trata de tener un tema bonito en GTK sino de que los controles sean parte de un espacio OpenGL, renderizados por OpenGL. GTK o Qt no ayudan a esto, ya que son toolkits orientados al escritorio que contienen un widget donde se puede dibujar con OpenGL. En definitiva, las soluciones anteriores permiten ‘empotrar’ un espacio OpenGL en una ventana, mientras que lo que pretendemos es todo lo contrario.

Así pues se plantean varias alternativas. En http://www.mathies.com/glfaq/GLToolkitFAQ.html podemos ver una lista de proyectos muy interesantes: toolkits para desarrollo a alto y bajo nivel y cosas así. La parte que más nos interesa en este momento es el apartado V, en el que se enumeran varios toolkits realmente interesantes.

Sin embargo, ninguno me ha gustado. ¿Por qué? Porque los que mejor pinta tienen son semejantes a GTK o Qt, es decir, OpenGL es sólo una parte del toolkit. En definitiva, no creo que con estos toolkits se pueda crear un espacio de trabajo como el del pantallazo anterior.

Así que sólo queda una opción: crearnos un toolkit.

Cabaret, por tanto, se construirá sobre un toolkit propio y completamente nuevo. Este toolkit estará diseñado para crear aplicaciones como la del pantallazo anterior, en las que la pantalla completa se convierte en un espacio de edición sobre el que flotan los diferentes paneles de herramientas. Los paneles serán pequeñas ventanas que contendrán controles como botones, slides, entradas de texto y quzá algo más. Además, para que este toolkit sea reutilizable hay que diseñarlo bien, tener una buena jerarquía de objetos y un buen control de los eventos. Los controles se pintarán mediante el motor que ya hemos creado para pintar texturas y textos, de forma que aprovecharemos el código ya creado y, por cierto, hará que el toolkit pueda tener diferentes temas.

Tiene buena pinta…

El Problema Fundamental

El problema fundamental que tenemos que resolver es ser capaces de mostrar fuentes y dibujos mediante OpenGL.

GLUT permite mostrar un conjunto fijo de fuentes en pantalla, así que no nos vale, porque las transparencias necesiitan diferentes fuentes y tamaños. Existen bibliotecas como FTGL que permiten renderizar fuentes truetype mediante polígonos, lo cual en principio puede parecer una buena idea pero no lo es. ¿Por qué?

La razón es que muchas tarjetas aceleradoras no permiten dibujar polígonos con antialias. Sorprendente pero cierto. Las ATI que montan los powerbook, como es mi caso, no lo permiten, ni siquiera los últimos supermodelos de la marca.  Y las fuentes tienen que tener antialias. Existe una solución que se suele utilizar para estos casos y es FSAA, Full Scene Antialias. En realidad FSAA es un poco chapucero: en lugar de antialias lo que se hace es utilizar el buffer de acumulación (un “sumador de imágenes”) para acumular una imagen renderizada con ligerísimas variaciones del punto de vista. De esta forma se superponen varias imágenes ligeramente desplazadas, lo cual produce un suavizado en todos los bordes de la imagen resultante.

Para muestra un botón. En cualquier caso, me parece una solución a medias, porque si bien nos reduce la complejidad para renderizar las fuentes (utilizando FTGL por ejemplo) nos obliga a hacer algo inherentemente complejo. Y fuera de lugar, para qué engañarnos. O sea: no me gusta esa solución.

La típica solución para estos casos es renderizar las fuentes en bitmaps y utilizarlos como texturas de polígonos OpenGL. Esta solución aporta dos grandes ventajas:

1. Fuentes de tanta calidad como tu renderizador de fuentes te permita.
2. El mismo motor para mostrar las texturas en polígonos se puede aprovechar para las imágenes, o sea, matamos dos pájaros de un tiro.

Está claro que la limitación de la calidad está en el punto 1, ya que pintar un polígono con una textura es sencillo y queda muy bien. La biblioteca para crear imágenes por antonomasia es libgd. Y es realmente buena. Renderiza fuentes TrueType2 con antialias y queda fenomenal. Además se puede aprovechar para importar imágenes, o sea que todo son ventajas. La cosa está clara.

Bienvenidos al Cabaret

Es un placer que la propuesta de Cabaret haya sido aceptada en el I Concurso Universitario de Software Libre. Espero estar a la altura y hacer de Cabaret una realidad.

La idea de Cabaret lleva bastante tiempo rondándome. La motivación fue simple: en el GUL al que tengo el placer de pertenecer organizamos jornadas de cursos en los cuales alguna vez he participado. La idea de dar las charlas con transparencias nunca me gustó, pero admito que es muy útil especialmente si la audiencia no se va a dedicar a tomar apuntes. Por ello opté, para dar una charla sobre PostgreSQL, por prepararme unas cuantas. Probé OpenOffice, que resulta realmente sencillo de usar, pero el resultado era realmente malo. Nadie en su sano juicio usaría fuentes sin suavizar en el siglo XXI.

Pero no quería usar Keynote: no es libre y es demasiado caro para usarlo de pascuas a ramos. Así que opté por LaTeX Beamer, un paquete de LaTeX que hace unas transparencias realmente buenas. Obviamente la salida es PDF así que olvida todo lo relacionado con transiciones y movimientos. No es que me gusten demasiado, pero de vez en cuando pueden ser muy apropiados. La experiencia resultó muy buena, excepto por una cosa: es LaTeX. O sea, olvida la sencillez, la facilidad de uso, la intuitividad y esas cosas que no pueden faltar en un escritorio del año en curso.

Desde entonces, cómo no, llevo pensando en Cabaret. Incluso he llegado a hacer alguna prueba de concepto que mis compañeros guleros han visto. Ahora toca coger el toro por los cuernos y dejarnos de pruebas de concepto: hay que construir un Cabaret.

Si nos asomamos a la forja del proyecto, vemos que está en fase Planning. Eso significa que hay que escribir en algún sitio un plan te ataque del proyecto. Sea pues:

• Cabaret se basará en GLUT sobre OpenGL. La razón es que GLUT está muy extendido, existe una implementación libre que llevan de serie las distros como Ubuntu, por ejemplo, y es muy sencillo de usar. Tiene alguna cosa mala, como por ejemplo el soporte de tildes en algunos sistemas como Mac, en Linux creo que funciona bien.
• Cabaret se usará mediante una GUI: olvidemos escribir las transparencias mediante comandos y etiquetas. Pero la GUI debe ser realmente completa, por lo que nos va a hacer falta un buen toolkit para OpenGL
• Cabaret guardará los documentos en XML. Habrá que hacer algún uso de bibliotecas XML o generarse un parser para leer este formato. Habrá que sopesar libxml o alguno de esos, pero lo más probable es que acabe haciéndome una clase sencillita y punto.
• Cabaret soportará animaciones y transiciones mediante plugins. Este es un punto difícil porque estas transiciones y animaciones dan lugar a las horteradas mas brutales que podamos ver nunca. Así que el soporte para plugins será pequeño y muy simple, orientado a hacer las cosas sencillas y, ante todo, que no salga un clip con ojos borrando unas letras y escribiendo otras

Con estas premisas en mente, ya podemos comenzar a programar algo.