Hace unos meses atrás estaba por comenzar un proyecto, el cual requeriría un uso intensivo de procesamiento y manipulación de gráficos 2D. Luego de meditar un poco, decidí darle una oportunidad a SWT. Supuse que al su premisa de aprovechar los recursos nativos de cada sistema operativo repercutiría favorablemente en la performance. Busqué en la web evidencias que respaldaran mis suposiciones, haciendo especial hincapié en el uso de aceleración por hardware pero no encontré nada determinante. Tampoco pude encontrar comparativas de performance entre SWT y Java 2D.

Así las cosas, comencé el desarrollo con SWT basándome solo en supuestos. Todo anduvo bien hasta que llegó la hora de programar la funcionalidad de zoom. Una vez finalizada, mientras testeaba dicha funcionalidad, realicé la siguiente prueba: primero generé un nuevo documento, que consistía en una matriz cuadrada de 200 casilleros de lado. Cada casillero es a su vez un cuadrado compuesto por 40 píxeles de lado. Navegué por la ventana, configurando la vista a diferentes niveles de zoom y usando las barras de desplazamiento. A medida que alejaba la vista y más celdas se visualizaban simultáneamente, comenzó a hacerse evidente una ralentización en la performance.

En el nivel más bajo de zoom, casi lograba visualizar la totalidad de las 40.000 celdas que componían el modelo completo. Con ese factor de zoom activo la aplicación tardaba alrededor de 7 segundos en terminar de renderizar todas las celdas, corriendo en un hardware de término medio. Eso era demasiado a mi criterio.

Entonces decidí hacer lo que en realidad debería haber hecho desde un principio: desarrollé una prueba relativamente sencilla de performance comparando SWT por un lado y Java 2D por otro. El API Java 2D es un componente estándar de la plataforma Java SE, por lo cual no es necesario referenciar a ninguna librería adicional para poder utilizarlo.

La prueba solo abarca el caso puntual al que hago referencia. De ninguna manera pretende comparar todas y cada una de las características gráficas disponibles en ambas librerías. En síntesis lo que hace es copiar una misma imagen una determinada cantidad de veces, llenando la superficie de otra imagen. La imagen original es escalada de forma tal de que todas las copias quepan en el destino, una al lado de la otra. Este proceso se repite una cantidad predefinida de veces y por último se muestra la imagen final en pantalla.

Para la ejecución de los test se copió una imagen cuadrada de 40 píxeles de lado en una grilla también cuadrada de 100 x 100 posiciones. Con esto ya tenemos 10.000 copias. Además, la misma prueba se ejecuta 20 veces seguidas. Por último, el test completo se repite 5 veces para obtener datos más generales. Todas las mediciones están expresadas en milisegundos.

Los resultados de las mediciones de tiempo realmente me sorprendieron. Java 2D resultó entre 3 y 12 veces más rápido que SWT, dependiendo en entorno de tiempo de ejecución. Mi hipótesis es que SWT no está utilizando la aceleración por hardware o bien no hace un uso muy eficiente de la misma. No se me ocurre otra explicación.

Recursos

Código fuente de ambos test. También se incluye la imagen de prueba y los archivos de proyecto específicos para Eclipse: Descargar

Tags: swing, SWT, benchmark, acceleration, performance, comparison