Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found in GNU Free Documentation License.
GTK+ es una interfaz gráfica de usuario que te permite escribir aplicaciones modernas y faciles de utilizar. Fue originalmente escrita para su uso con el sistema X Window, pero ya la versión 2.0 soportaba otros sistemas de ventanas. La versión descrita en este papel, la versión de framebuffer para GTK (o algunas veces sólo GtkFB), se ejecuta sin ningún sistema externo de ventanas. En vez de eso, esta versión de framebuffer utiliza el propio dispositivo framebuffer de Linux.
Un framebuffer es un dispositivo hardware de Linux que el kernel exporta a los programas que se ejecutan en espacio de usuario, dando a estos programas el acceso a la tarjeta gráfica. Teniendo acceso a la tarjeta de gráficos se consigue que los programas que utilizen framebuffer puedan cambiar la resolución/disposición de bits y leer/modificar la memoria de la tarjeta gráfica. La mayoría de puertos embedidos en Linux tienen drivers para los dispositivos framebuffer para su tarjeta de video, y hay drivers para la mayoría de las tarjetas gráficas de escritorio. Ambos drivers permiten que esta versión de GTK+ sea utilizado en tales controladores.
GTK+ tradicionalmente ha utilizado la xlib para hacer llamadas desde una red a un servidor X que maneja el pintado en pantalla, la entrada de teclado, la gestión de varias ventanas, etcétera. Esta arquitectura cliente/servidor es muy útil, debido a que permite que varios programas se muestren en una misma pantalla a la vez, y debido a que la comunicación es sobre una red, incluso no necesitan ser ejecutados en un mismo ordenador. Es también una buena manera de estructurar un gran sistema, debido a que el servidor X de confianza contiene un montón de controladores de dispositivos de bajo nivel dependientes del sistema, otros programas no necesitan hacerlo, y ni siquiera deberían permitirles hacerlo.
La arquitectura cliente/servidor tiene algo de sobrecarga, como toda la comunicación que se da sobre una red, y algo de información está duplicada en el servidor y el cliente por razones de rendimiento. Debido a que GtkFB no utiliza las X, es apropiado en sistemas o entornos donde la memoria disponible y de almacenamiento es muy bajo y donde la transparencia de red no es necesario, tales como en dispositivos empotrables.
GtkFB, sólo por ser GTK+, depende de unas cuantas librerias básicas:
Tabla 1. Dependencias de librerias Descripción de la libreria Glib contiene los tipos de datos básicos y funciones necesitadas por el típoco programa escrito en C. Pango contiene soporte para texto y fuentes en la mayoría de lenguajes y scripts. libpng, libjpeg, libtiff se utilizan por los cargadores de imágenes. Son opcionales. y necesarios sólo si tu quieres cargar un determinado tipo de imágen. La libreria Freetype se utiliza en la versión de framebuffer. Se utiliza para renderizar fuentes TrueType y Type1.
GTK+ compila tres librerias: gdk-pixbuf, gdk y gtk. Gdk-pixbuf es una libreria para la carga, almacenamiento y manipulación de imágenes; gdk es una capa de abstracción entre nuestro sistema de ventanas y el sistema gráfico; y gtk es la libreria de alto nivel de interfaz gráfica con el usuario. Casi todo el código específico de framebuffer está en la libreria gdk, que es llamada por el código gtk, pero hay algo de código especifico de framebuffer especifico en gtk para manejar las ventanas.
La libreria gdk tiene tres tareas básicas: dibujar gráficos, manejar ventanas solapadas y generar eventos. En el núcleo de gdk están las primitivas o funciones que te permiten dibujar lineas, polígonos, texto y más cosas aún. Esto es muy similar al sistema X Window; de hecho, se utiliza una versión modificada de la libreria de rasterización X (libmi). Manejar ventanas solapadas, significa guardar un árbol de ventanas actualizadas sobre la pantalla y asegurarte de que cuando dibujas en una ventana, no estás dibujando las ventanas solapadas. Los eventos se generan cuando hay una interrupción provocada por el usuario o cuando el sistema de ventanas necesita decirle a la aplicación alguna cosa, como la necesidad de volver a dibujarse una ventana, o que el ratón se ha movido de una ventana a otra. Los eventos generados son un subconjunto de los que se generan en las X, debido a que GTK no necesita todos los eventos y la información de eventos que nos proporcionan las X.
Cuando un programa enlazado a las librerias GtkFB comienza, normalmente llama a gtk_init() en el arranque. En este punto, GtkFB abre el dispositivo framebuffer (y opcionalmente se cambia a la resolución y disposición de colores deseada), el teclado, y el dispositivo del ratón. Escanea un conjunto específico de directorios para las fuentes, y entonces procede a inicializar la ventana y el sistema de eventos.
GtkFB ha realizado drivers para el teclado y varios tipos de ratones, incluyendo los de pantalla tactil. Si se necesitan otros controladores, es muy fácil añadir un nuevo controlador. GtkFB actualmente no utiliza ningún tipo de aceleración hardware, pero el soporte para la aceleración hardware para determinadas tarjetas gráficas podría ser añadido. Actualmente resoluciones de 8, 16, 24 y 32 bits por punto son soportados por framebuffer.
GTK+ originalmente viene del proyecto GIMP, donde fue desarrollado para escribir su interfaz gráfica de usuario. Fue más tarde dividido el proyecto debido a que ha sido utilizado por muchos otros programas, incluyendo el proyecto de escritorio GNOME.
La versión más utilizada de GTK+1.2 está basada en el sistema X, pero fue portada a Win32 sustituyendo la libreria gdk y añadiendo algo de soporte de la glib a Win32. Este soporte nunca fue incorporado en la versión 1.2, pero debido a que se paso a la 2.0, la versión de Win32 fue incluida.
Durante el verano del 2000, Elliote Lee de Red Hat empezó a escribir la versión de framebuffer de gtk. Alex Larson tomo el trabajo de GtkFB en Octubre del 2000 y ha estado trabajando en ello desde entonces.
En la versión de GTK+2.0, la versión de framebuffer estará completamente funcionando en GTK+, con todas las características de la versión de las X.
El principal beneficio con GtkFB es que puedes utilizar la potente libreria GTK+, con su gran cantidad de software, en lugares donde el tamaño tan grande de las X no se quiere, tales como PDAs y otros dispositivos empotrables. La API es tambíen exactamente la misma que la versión de escritorio, así que el código puede ser facilmente portado y compartido entre el escritorio y dispositivos embebidos.
Otro importante beneficio de GtkFB es que eres libre, e incluso se te anima, a modificar el código fuente de la libreria para que se ajuste mejor a tus necesidades (en terminos de tamaño y características). Es fácil recortar GTK+ para que se ajuste a tus determinadas necesidades. Debido a la licencia LGPL, necesitas liberar tus cambios de la propia libreria, pero no necesitas liberar el código de tus propios programas.
GtkFB es también libre de costes, licencia o demás, tu propio desarrollo no cuesta nada.
Además, debido al hecho de que GtkFB no utiliza el protocolo de las X, algunas viejas limitaciones de las X han sido levantados. Todo el texto está renderizado con anti-aliasing en 256 escalas de grises. Los colores por defecto pueden estar en cualquier disposición de colores, y soporta rotación de pantalla en tiempo de ejecución.
Por supuesto, GtkFB tiene también limitaciones. La principal limitación es el modelo uni-proceso. Todo el código en el sistema debe estar en el mismo binario y ejecutarse en el mismo proceso. Esto significa que tu no puedes utilizar procesos para separar y proteger diferentes partes del sistema de otros. También hace más dificil de diseñar grandes sistemas.
Otro problema es que algunos programas GTK+ hacen llamadas a las X de forma directa utilizando características de las X que no están soportadas en Gdk. Estos programas no pueden utilizarse con GtkFB sin cambiarse. Las librerias de GNOME hacen algunas llamadas directas a las X, así que ejecutar programas de GNOME con framebuffer podría necesitar algo de trabajo.
Algunas otras interesantes características de las X no están soportadas por framebuffer, tales como la transparencia de red, DGA, multiples pantallas y soporte visual, extensión Xv y extensión Xrender.
Para evaluar los requerimientos de memoria y almacenamiento, he compilado una pequeña versión de GtkFB en una máquina x86. Haciendo más trabajo aún con los flags del compilador y quitando características que no estás utilizando, puedes hacer que tus binarios sean más pequeños.
Aquí están los flags utilizados para construir las librerias:
glib: ./configure --enable-debug=no --disable-mem-pools pango: ./configure --enable-debug=no --with-included-modules=yes gtk+: ./configure --enable-debug=no --with-gdktarget=framebuffer --disable-shadowfb --disable-modules --with-included-loaders=xpm,png,jpeg
Esto incorpora tanto librerias estaticas como compartidas. Por sencillez, he incorporado los cargadores de imagenes xpm, png y jpeg en gdk-pixbuf. En un caso del mundo real, probablemente utilizarías los cargadores de imagenes cargados de forma dinámica si eligieses utilizar librerias compartidas.
Con esta división, las librerias compartidas de GtkFB ocupan alrededor de 2MB en espacio de disco. Adicionalmente FreeType 202KB, libjpeg 138 KB, libpng 126KB, libz (necesitada por libpng) 58KB.
Para dar una sensación del uso de memoria, ejecuté el programa testgtk (incluido en las fuentes de GTK+) que muestra varios widgets. Abrí tres ventanas llamadas button box, buttons y clist y entonces analizé los requerimientos de memoria. Estimando los requerimientos de memoria en un sistema con memoria virtual es un poco difícil, debido a que la memoria puede ser dinamicamente paginada a disco y fuera de disco.
El tamaño RSS (la cantidad total de memoria física utilizada, sin contar las páginas que han sido intercambiadas a disco) era de 3.4 MB. En Linux una página de una libreria compartida no es escrita a swap sino que sólo se descarta, del modo que pueda ser solamente leida desde un archivo cuando se necesite de nuevo. El tamaño total de la memoria virtual era de 6.6 MB, de la que 2.3 MB era compartida con otros procesos. Del tamaño de la memoria virtual total 940KB está el framebuffer mapeado, lo cual no es memoria RAM real.
Algunas estadisticas más aun de memoria: 72KB es la fuente Arial mapeada, 112KB es la información de los locale mapeada, 1444KB es el código de la libc mapeado, y 120KB es el programa binario mapeado. El puntero es de 836KB y la pila es de 24KB.
Es interesante comparar esto con un binario enlazado estaticamente, debido a que cuando enlazas estaticamente solo los archivos objeto realmente usados por el programa, son enlazados en el binario. Por comparación, compilé una versión de testgtk que había sido enlazado estaticamente casi todo exceto la libc (incluyendo la libm).
El binario enlazado estaticamente es de 1.8 MB, y depende de la libc, libm, libdl y ld-linux unicamente. El RSS fue ligeramente más pequeño, de 2.5 MB, el tamaño de memoria virtual era de 5.2 MB, y 1.7 MB eran memoria compartida. Las otras estadisticas son las mismas que en el caso enlazado estaticamente.
El programa testgtk utiliza una gran cantidad de widgets y características de GTK+ que hacen que enlazarlo estaticamente produzca una gran cantidad de código. Para ver el tamaño de un programa mínimo se puede compilar el ejemplo buttons.c distribuido con GTK+. Solo abre una ventana con un botón que contiene una imágen y una etiqueta. El binario es de 1.3 MB, RSS fue de 1.9 MB y el tamaño de la memoria virtual fue de 4.4 MB. El puntero es de 376KB y la pila de 20KB.
Si otros cuantos programas que utilizan la libc son utilizados en el sistema tu podrías querer enlazarlos estaticamente también. Un completo enlazado estatico de los binarios (incluyendo libc y libm) son de 2.1 MB para testgtk (RSS 2.5 MB , memoria virtual de 5.4 MB) y 1.7 MB para los botones.
Es conveniente hacer una rápida comparación con GTK+ basadas en las X. Compilé una versión de las X utilizando los mismos flags que la versión de framebuffer. Ejecuté testgtk (utilizando librerias compartidas) en un servidor X que tenía sólo twm ejecutándose.
El tamaño total de la memoria virtual de testgtk fue de 6,6 MB, y el RSS fue de 4MB. 980KB de librerias mapeadas que están presentes no lo estaban en la versión de GtkFB (Las librerias X y threads). La versión de las X de pango es ligeramente más grande, debido a que tiene algunos tipos más de lenguajes extranjeros. El servidor de las X (XFree86, servidor Matrox) tiene un tamaño total de memoria virtual de 9.2MB, sin contar la memoria de video ram mapeada. RSS es de 7.9 MB. Algo de la memoria es compartida con testgtk (algo alrededor a 2MB). Adicionalmente twm tiene un tamaño de gestor de ventanas de 3.2 MB y un RSS de 1.6 MB pero hay gestores de ventanas más pequeños, e incluso puede que ni llegues a necesitarlo.
Las librerias gtk y gdk-pixbuf son del mismo tamaño en disco, pero la libreria gdk X es 48 kb más pequeña. Dependencias añadidas para la versión de las X son libX11 (824kb), libXext (51kb) y libpthread (451KB, sólo necesitada si se utilizan librerias X con hilos). Además, necesitas un servidor X. Las XFree86 cuando se utilizan ocupan 1.5 MB, sin contar varios módulos de los controladores, pero hay servidores X más pequeños (tinyX ocupa cerca de los 700KB).
El resultado de este simple experimento muestra que los programas framebuffer con GTK+ son algo más pequeños que sus correspondientes versiones en las X, ignorando el tamaño del servidor X. Si tu añades un servidor X y un gestor de ventanas, la versión de las X se vuelve mucho más grande. Sin embargo, la versión de framebuffer para GTK+ tiene menor soporte para la gestión de ventanas que lo hace ideal para dispositivos pequeños donde la carga de las X puede ser demasiado grande para la memoria disponible.
Mucha gente cree que GtkFB sustituirá a las X en el escritorio. Esto es incomprensible: GtkFB realmente no está pensado para ejecutarse en el escritorio (excepto para específicos casos como en las instalaciones de distribuciones). Por las razones dadas en la sección de Limitaciones, GtkFB es inferior a las X en el tipico escritorio.
Una posible razón de este pensamiento es la típica falta de entendimiento de que el sistema X Window es un programa grande, extenso y lento que no hace demasiado bien. La verdad de esto es que los servidores X suelen mirar mucho a lo que tú ves por encima, pero esto es debido a que tienen completamente mapeada la memoria de la tarjeta gráfica, y ellos guardan gran cantidad de la información pixmap que realmente van a necesitar otros procesos. Debido a que las X es independiente de la red, nunca puede ser tan eficiente que otra que es dependiente de la red, el sistema de ventanas, pero el rendimiento que se pierde es realmente pequeño y se consigue una ganancia en resultados. Los problemas actuales con las X (manejo de fuentes, no Anti Aliasing, mal soporte 3d, no soporte de video), son actualmente corregidos por las extensiones X.
Las fuentes de GTK+ 2.0 beta (llamadas 1.3.x) pueden encontrarse en el ftp de GTK+. La versión 1.3.4 (no realizada cuando se escribió este articulo) será una buena versión si quieres probar GtkFB.
Además de glib, pango y GTK+ tu necesitas FreeType (2.0.1 o posterior), que puede encontrarse en el FTP de FreeType. Opcionalmente, para incluir el correspondiente cargador gdk-pixbuf, puedes utilizar libjpeg, libpng y libtiff.
La documentación especifica incluida en GtkFB está en gtk+/docs/README.linux-fb.
La ultima versión puede ser encontrada en el CVS de GNOME. Necesitarás bajarte y compilar estos modulos (en este orden): glib, pango y gtk+. La web de desarrolladores de GNOME contiene una descripción de como bajar los módulos del árbol CVS de GNOME.