1

2

3

4

5

6

7 Universidad De Almería



8 Escuela Politécnica Superior



                    Titulación: Ingeniero en Informática



9 Compresión Progresiva de Vídeo en Internet.




      Alumno:

      Sergio García Sanz.

      Almería, 28/05/2002



Directores:

Vicente González Ruiz.

Leocadio González Casado.



Introducción.



Objetivos de la memoria.



Plan de trabajo y organización de los apartados.


A continuación se detalla el plan de trabajo  seguido  a  lo  largo  de  los
meses que ha durado el proyecto. Esta organizado  en  varios  capítulos  que
muestra como ha ido evolucionando hasta conseguir el resultado final.


Capitulo 0: Breve descripción del  software  de  transmisión  de  video  que
existen en la actualidad.


Capitulo 1. En este capítulo detallaremos la base teórica de los  algoritmos
usados para la compresión y descompresión del video progresivo.


Capitulo  2.  En  este  capítulo  detallaremos  en  profundidad  el  trabajo
realizado. Se explicará como se ha desarrollado el software  servidor  y  el
software cliente de video progresivo.


Capitulo  3.  En  este  capítulo  detallaremos  las  distintas  simulaciones
realizadas con el software desarrollado teniendo  en  cuenta  los  distintos
factores que afectan al rendimiento.


Capitulo  4.  Se  detallarán   las   posibles   ampliaciones   al   proyecto
desarrollado.






Capitulo 2.


Explicación del sistema desarrollado.


En este apartado se describirá todo el trabajo realizado hasta conseguir  el
software cliente y servidor de video progresivo.


Durante  los  meses  nos  hemos  ido  planteando  objetivos  que  hemos  ido
cumpliendo hasta la finalización del proyecto. Estos objetivos los  vamos  a
ir describiendo en los distintos puntos de que consta este capitulo.


Introducción.


La idea principal con la que partimos a la hora de desarrollar el proyecto
era la de implementar un software cliente-servidor de video progresivo que
fuese capaz de adaptarse al ancho de banda de la red o incluso a las
exigencias de la máquina cliente donde el software iba a ejecutarse.


Por lo tanto tendríamos un software corriendo en una  máquina  (servidor  de
video progresivo) que escucharía peticiones  de  los  clientes,  los  cuales
solicitan videos comprimidos, que a la llegada  se  irán  descomprimiendo  y
mostrando por pantalla.


Una de las características del algoritmo de descompresión es  que  cumple  a
la perfección con esas dos características,  es  decir  no  nos  importa  el
ancho de banda que nos proporcione la  red,  el  algoritmo  se  comporta  de
forma correcta y es capaz de abandonar el trabajo en un momento dado.


Teníamos una idea general  de  lo  que  tenía  que  hacer  nuestro  software
cliente, esta idea estaba basada en un pipeline de tres etapas por donde  el
flujo del programa tenía que ir avanzando en el tiempo.  Estas  tres  etapas
generales eran:


Etapa 1: Lectura de los datos y descompresión.

Etapa 2: Transformada inversa del volumen.

Etapa 3: Visionado de las imágenes.



|         |Sg 1     |Sg 2    |Sg 3    |Sg 4    |        |
|Etapa 1  |L/D 1    |L/D 2   |L/D 3   |L/D 4   |...     |
|Etapa 2  |         |T 1     |T 2     |T 3     |T 4     |
|Etapa 3  |         |        |V 1     |V 2     |V 3     |





Siendo:


L: (lectura de datos).

D: Decodificación de los datos.

T: Transformada inversa.

V: Visionado de los datos.


Por lo tanto en un momento  dado  del  programa  estaríamos  trabajando  con
datos de hasta tres segundos distintos, es decir,  tendríamos  una  latencia
de dos segundos, ya que al tercer segundo empezaríamos a ver  el  video  por
la pantalla.


Por ahora no me preocupa indicar cual es la información que entra y sale  de
cada una de las etapas del pipeline porque mas  adelante  se  detallarán  en
profundidad.


Teniendo en la cabeza la idea general  de  como  tenía  que  comportarse  el
software cliente de video progresivo empezamos a trabajar.


Desarrollo de un visor de video.


Necesitábamos  disponer  de  un  software  que  fuese  capaz  de  reproducir
volúmenes de imágenes (conjunto de imágenes planas una  detrás  de  otra)  a
una velocidad de N imágenes por segundo, para ello usamos la  librería  Xlib
que nos permite trabajar con el entorno X de forma relativamente sencilla.


La rutina es muy sencilla de comprender. Como entrada tendría una matriz de
dos dimensiones (que sería un fotograma del volumen completo), el tamaño de
las filas y de las columnas. Con estos datos de entrada se genera una
ventana en entorno X, con la altura y la anchura indicada en los parámetros
y que cada uno de los puntos que forma la imagen son obtenidos de la matriz
que se le pasa como argumento.


Ejemplo de cómo se representa un fotograma.



for(i=0;i<filas;i++) {

    for(j=0;j<columnas;j++) {

      int x=matriz[segundo][i][j];

      XPutPixel(ximage,j,i,RGB[x]);

    }

  }


XPutImage(....,filas,columnas);


La función XPutPixel rellena una matriz  en  memoria  con  un  píxel  de  un
color, una vez que hemos  recorrido  toda  la  imagen  es  cuando  realmente
mostramos el fotograma por pantalla con la función XPutImage,  esta  función
es costosa y por lo tanto hay que evitar llamarla de forma innecesaria.

Para que el visionado del video fuese dinámico,  ya  que  hasta  ahora  solo
somos capaces de mostrar un fotograma, lo encapsulamos todo en  una  función
a la que se la llamaría  de  forma  periódica  en  un  intervalo  de  tiempo
definido.


Para poder llamar a la función cada vez que tuviésemos  que  representar  un
fotograma usamos interrupciones mediante señales del sistema operativo.


La explicación de las señales la  haremos  más  adelante  cuando  detallemos
cada una de las partes del cuerpo de cliente.


La parte del visionado de los volúmenes en la aplicación  cliente  varía  un
poco con respecto  a  esta  primera  aproximación,  pero  respeta  la  misma
filosofía de trabajo.



Formato de la información a transmitir.


El formato del video comprimido  tiene  una  serie  de  características  que
vamos a describir en este apartado.


Para generar un video progresivo que el software desarrollado sea  capaz  de
interpretarlo y actuar en  consecuencia  es  necesario  tener  un  video  en
formato RAW (video que no tiene ningún tipo  de  compresión,  es  decir  que
todos los fotogramas  del  video  son  imágenes  en  dos  dimensiones).  Con
cualquier WebCam o videocámara digital podemos  obtener  una  secuencia  con
estas características.


Una vez tengamos el video plano, debemos comprimirlo  con  el  algoritmo  de
compresión SPIHT3D que nos genera un fichero con un formato especial.


Este formato está adaptado para el proyecto de video progresivo,  no  quiere
decir que esta sea la salida para cualquier otra aplicación.


Formato del fichero comprimido.


|X bits  |Y bits                          |

Siendo:


N: Tamaño del GOF completo.

X: Información solicitada por el cliente.

Y: Información restante del GOF.




Descripción  de  las  Distintas  Implementaciones  del  Cliente   de   Vídeo
Progresivo.


La mayor parte del tiempo se ha empleado en el desarrollo de un  cliente  de
video. A lo largo del proyecto lo hemos ido mejorando  hasta  encontrar  una
solución  óptima,  estas  mejoras  han  sido  por  encontrar  problemas   de
rendimiento, por optimizar el medio de transmisión, etc.


En este  apartado  vamos  a  hacer  una  descripción  de  cada  una  de  las
implementaciones realizadas explicando el  funcionamiento  y  los  problemas
encontrados que han dado motivo a una nueva versión.


Primera implementación.


En la primera implementación la información del GOF no se obtiene a través
de un socket de comunicaciones sino a través de una lectura directa del
video codificado. Se realizó de esta forma para ir paso a paso
complicándolo cada vez más.


La idea, era ver la forma de realizar las tareas en paralelo, para  ello  lo
primero que nos vino a la cabeza era  usar  los  procesos  ligeros  ó  hilos
(threads) de Linux.


Los threads son procesos ligeros que permite la  ejecución  en  paralelo  de
distintas tareas. Una de las principales ventajas que tienen  es  que  todos
los procesos lanzados  comparten  la  memoria,  esto  nos  permite  realizar
comunicación entre ellos sin demasiado problema, lo único a tener en  cuenta
es la sincronización y el uso  cerrojos  para  que  las  lecturas/escrituras
sobre las variables críticas se realicen de forma atómica.

Diseñamos tres procesos, uno que realizaba la  lectura/Decodificación,  otro
que realizaba la transformada inversa (DWT-1) y  otro  que  representaba  el
volumen, estos procesos eran lanzados en el main del cuerpo del  programa  y
estaban sincronizados  mediante  cerrojos  para  que  cada  etapa  comenzara
cuando los datos estuvieran disponibles.


Una representación gráfica de la implementación:

























Como tenemos 3 etapas  tendremos  un  retardo  de  2  intervalos  desde  que
empezamos  a  leer  hasta  que  comenzamos  a  visualizar  el  primer   GOF,
necesitamos tener un doble buffer de los volúmenes  para  seguir  trabajando
en los distintos etapas del pipeline sin que la salida de un proceso  altere
los datos de la entrada de la siguiente etapa.


Para el doble buffer necesitamos reservar memoria para variables del tipo:



      Volumen  =(int ***)calloc(pics,rows,cols,sizeof(int));



La función calloc utilizada para la reserva de memoria es una  encapsulación
de la función malloc de UNIX. Esta función reserva memoria para  un  volumen
de enteros.




La forma gráfica de la variable Volumen:




















Si nuestro programa siguiera un orden  secuencial,  para  un  instante  dado
esta sería la secuencia de procesamiento:



Instante 1

Lectura/Decodificación(Fichero,VolumenProceso1)

      Transformada_Inversa(VolumenProceso2, VolumenPintado1)

      Pintado(VolumenPintado2)


Instante 2

Lectura/Decodificación(Fichero,VolumenProceso2)

      Transformada_Inversa(VolumenProceso1, VolumenPintado2)

      Pintado(VolumenPintado1)


Instante 3

Lectura/Decodificación(Fichero,VolumenProceso1)

      Transformada_Inversa(VolumenProceso2, VolumenPintado1)

      Pintado(VolumenPintado2)


Instante ...

Lectura/Decodificación(Fichero,VolumenProceso2)

      Transformada_Inversa(VolumenProceso1, VolumenPintado2)

      Pintado(VolumenPintado1)


De esta forma conseguimos tener un flujo  continuo  de  procesamiento  pero,
necesitamos tener un doble buffer en las etapas  de  lectura/decodificación-
Transformada_Inversa y otro doble buffer en las etapas Transformada_Inversa-
Pintado.



Conclusiones.


Los resultados obtenidos con la implementación del  cliente  usando  Threads
fueron muy desalentadores, el motivo de esta respuesta es que  los  procesos
tardaban más tiempo en ejecutarse  del  disponible  haciendo  inviable  ésta
primera aproximación.


Una respuesta a lo  sucedido  puede  estar  en  que  teníamos  dos  procesos
intensivos en CPU (Decodificación y  Transformada  inversa)  y  se  perdiera
mucho tiempo conmutando de un proceso a otro con la consecuente  pérdida  de
rendimiento.


Aparte del proyecto y para comprobar si el problema eran los  Threads  o  la
propia implementación del cliente realizamos  varios  programas  simples  de
cálculo intensivo usando y sin usar Threads, el resultado fue  sorprendente;
el uso de Threads en procesos de calculo intensivo reduce en  un  40-50%  el
rendimiento de la CPU con respecto al mismo programa sin usar Threads.


Segunda Implementación.


Debido al fracaso de la primera implementación y a la imposibilidad de usar
Threads para ejecutar tareas en paralelo tuvimos que cambiar la forma de
enfocar el problema.


Pensamos que sería bueno que las funciones de calculo intensivo estuviesen
en el mismo proceso para evitar el problema ya conocido, por lo tanto las
funciones de decodificación y transformada inversa estarían en el mismo
proceso.


Aún nos quedaba conseguir la forma de ejecutar la lectura del fichero y la
representación del volumen, de forma paralela. Para conseguir este
propósito, dentro de la función de representación del volumen, que era
ejecutada por una interrupción, introducimos el código referente a la
lectura del GOF.


El funcionamiento de la interrupción es muy simple y a la vez muy potente.
Se declara una señal y se configura para que se ejecute cada un cierto
intervalo de tiempo X = Tmax/NFotogramas segundos ya que fue lo que
consideramos más oportuno.



Siendo:


X: Intervalo de tiempo en que se ejecuta cada interrupción.

Tmax: El tiempo máximo de procesamiento de un GOF.

NFotogramas: El número de fotogramas de que está compuesto el GOF.


De esta forma, si tenemos un fichero comprimido donde cada GOF contiene 16
fotogramas y queremos visualizarlo a 16 fps (frames por segundo) nuestra X
= 1/16 sg ó 62.5 milisegundos.



Una representación gráfica de la implementación:






























Esta implementación se comporta de la siguiente forma; una vez que hemos
leído los parámetros del fichero y hemos reservado memoria para los
volúmenes comienza un bucle hasta final de fichero donde se realiza la
decodificación y transformada una detrás de otra de forma continua salvo
las pequeñas interrupciones donde se lee el total del volumen (GOF) y se
representa un fotograma del volumen anterior. En esta implementación la
lectura no produce ningún retardo en el sistema.


Una vez que el proceso de transformada termina, se queda esperando en un
cerrojo hasta que se hayan terminado de representar los fotogramas y una
vez terminado sale del cerrojo y comienza la siguiente decodificación.


Si es la función de representación quien termina y la información para el
siguiente instante aún no está disponible (porque la decodificación ó la
transformada inversa no ha terminado) se pierde el sincronismo y la
visualización no se realiza de forma adecuada.


En esta versión el rendimiento es el esperado ya que se consume el tiempo
de CPU en la parte de decodificación y transformada (que es lo normal)
mientras que en la parte de lectura y representación el consumo es mínimo.


En cuanto a la memoria esta implementación necesita tener un doble buffer
para la lectura y otro para la decodificación y transformada, con el
consecuente ahorro de memoria con respecto a la versión anterior.



El buffer de lectura es almacenado en una estructura del tipo:


      vector = (char *)malloc(BITS_TO_DECODE*sizeof(char));


donde:


BITS_tT_DECODE: Es el número de bits máximo que vamos a leer de cada GOF y
que es definido al comienzo de la ejecución.



El buffer de decodificación y transformada inversa es almacenado en una
estructura del tipo:


      volumen = (int ***)calloc(pics,rows,cols,sizeof(int));



Conclusiones.


La versión se comporta de una forma "normal", es decir no se pierde ningún
tiempo extra en los cambios de tareas.



   Esta implementación sigue sin tener retardo en las lecturas, cuando
cambiemos la forma de obtener la información de un fichero a un socket nos
encontraremos con problemas que ahora no se nos han presentado.


Otro inconveniente encontrado es que si la CPU no es capaz de procesar el
GOF antes de que se termine la representación del volumen anterior, se
pierde el sincronismo. En posteriores versiones trabajaremos en este
apartado.




Tercera Implementación.


Una vez conseguido mediante la implementación anterior un visor de video
progresivo para ver videos en la máquina local nos vamos a centrar en
cambiar la forma de obtener los datos para que leamos la información de un
socket, es decir, en esta versión se comienza a tener comunicación con la
parte servidora del proyecto.


Las funciones de decodificación y transformada inversa no sufrieron apenas
modificaciones, pero, la parte de lectura sí que se sufrió modificaciones.


Como ahora las lecturas (que se hacen cuando se ejecuta la interrupción) se
realizan desde un socket, la información recibida puede ser distinta en
cada lectura, unas veces leeremos más y otras veces menos, por eso tenemos
que ir almacenando la información recibida en una estructura y cuando
vayamos a procesar el siguiente GOF que esa estructura esté disponible para
las funciones de decodificación y transformada. La idea, es ir leyendo la
información que esté disponible en el socket en cada uno de los intervalos
que dura la reproducción del GOF y en la última interrupción conmutar al
doble buffer y el que está cargado de información que pase a procesamiento.
Esta forma de actuar tiene dos problemas que más adelante detallaremos.


Una vez en la última interrupción pedimos otro GOF al servidor para que se
produzca una cadencia de envío y recepción. Esta forma de actuar es similar
a los algoritmos de parada y espera (Stop & Wait) de transmisión de
información estudiados en las asignaturas de redes.


Como es posible que parte de la información referente a un GOF en
particular no llegue a tiempo de poder ser útil hay que descartarla, esto
se realiza al comienzo de las lecturas.




Una representación gráfica de la implementación.






























La estructura del buffer utilizada para almacenar la información leída del
socket es la siguiente:



      Vector = (unsigned char *)malloc(bits_to_decode*sizeof(unsigned char))


Esta estructura se diferencia con respecto a la de la versión en  los  tipos
de datos que almacena, que ahora  son  unsigned  char  mientras  que  en  la
antigua eran char, el motivo es optimizar la información que  se  envía  por
el canal.


La forma de ir almacenando la información en el buffer de lectura es la
siguiente, al realizar una lectura del socket, la función usada tiene como
salida el número de bytes leídos, de esta forma vamos avanzando el puntero
dentro del vector y también gracias a esa información sabemos la cantidad
de bytes que restan por recibir.



Un ejemplo de lectura y avance del puntero es el siguiente:



      Nbytes = ReadNBytes(sock, vector,bytes_left)

      Vector = vector + nbytes


Siendo ReadNBytes la siguiente función:


      int ReadNBytes(int sock, unsigned char *buf, int bytes)

      {

        int nbytes=0;



        nbytes=read(sock,buf,bytes);

        return(nbytes);

      }


Una vez que estamos en la última interrupción y como última operación de la
función realizamos una petición al servidor con la cantidad de bytes que
nos tiene que enviar para el siguiente GOF. Si pedimos pocos bytes, estamos
desaprovechando el canal y estaremos visualizando el video con calidad
inferior a la que es posible. Si pedimos demasiados bytes, estamos
saturando la red con información que nos llegará tarde y que tendremos que
deshacernos. En esta versión el número de bytes que pedimos es la media de
las X últimas peticiones, siendo X una constante del programa, con esta
solución obtenemos buenos resultados.



En términos generales esta implementación funciona bien bajo  ciertos
ambientes (cuando la red es capaz de enviar la cantidad de información
pedida y cuando la CPU es capaz de procesar toda la información), pero
cuando alguna de estas características no se cumple, se producen una serie
de problemas.


Uno de los problemas detectados es debido a que los sockets utilizados son
"bloqueantes". Un socket es bloqueante cuando se queda esperando en la
función de lectura hasta que llegue alguna información por pequeña que sea.


En nuestra implementación esto repercute de la siguiente forma, cuando
realizamos una lectura del socket, si hay información en él todo va bien,
pero si no hay información que leer, la función se queda bloqueada, si el
tiempo que tarda en llegar la información es pequeño, apenas afecta al
rendimiento y por consiguiente a la visualización, pero cuando el retraso
es grande, la visualización sufre "congelaciones" en la imagen. Cuando la
información llega con retraso y hay que deshacerse de ella el problema se
agrava ya que estamos perdiendo tiempo en algo que no nos va a servir y que
está bloqueando la ejecución.



Además del problema de la "congelación" existe el problema que no estamos
aprovechando todo lo que se podría el canal ya que no estamos usando la
información que nos llega tarde.


También seguimos teniendo el problema de que si la función de
decodificación y transformada inversa termina tarde, la sincronía se
pierde.


Conclusiones.


Esta implementación se comporta de forma adecuada en la mayoría de las
situaciones, pero para versiones posteriores hay que solucionar o suavizar
los problemas encontrados durante la programación y posterior ejecución de
secuencias de video en diferentes circunstancias.




Cuarta Implementación.


La última implementación nos abrió el camino a nuevas mejoras en el diseño
del visor siempre que fuésemos capaces de solucionar los "defectos" de la
versión anterior.


Esta versión se centra en corregir el problema de la congelación cuando la
información no llegaba al socket con la suficiente cadencia y también el
problema de intentar aprovechar el canal de una forma más adecuada.


Para el problema de la espera en los sockets la solución fué la de usar
socket de tipo "no bloqueantes", la característica fundamental de este tipo
de conectores, es que si al hacer una lectura sobre ellos no existe
información no nos obliga a esperar hasta que la haya.


Para el problema de intentar aprovechar mejor el canal y por tanto la
información que no llega a tiempo para ser procesada fue la de implementar
un buffer de tamaño N donde tendríamos ese intervalo de tiempo asegurado si
la información escasea para que la reproducción no se vea afectada. De esta
forma,  la información leída puede llegar fuera de tiempo siempre y cuando
no supere el tiempo necesario para vaciar el buffer.


La incorporación de estas dos mejoras en el sistema solucionan del todo las
congelaciones de la imagen observadas en la versión anterior que se
producían cuando en las lecturas no había información que leer, tanto la
que estaba dentro de tiempo como la que había que leer para deshacerse de
ella por estar fuera de tiempo. Además esa información que antes la
"tirábamos" ahora es perfectamente útil con lo que mejoramos el
aprovechamiento del canal de transmisión.


La definición del buffer de lectura y de procesamiento para esta
implementación varía con respecto a la anterior ya que ahora es buffer no
es de tamaño dos, sino que será de tamaño N, parámetro definido al comienzo
de la ejecución.


Por lo tanto la definición del buffer de lectura es el siguiente:


      Desplazamiento = Bytes(bits_to_decode);



      Buffer = (unsigned char *)malloc( Tamano_Buffer * Desplazamiento *
      sizeof(unsigned char))





      Siendo:


Desplazamiento: El numero de bytes necesarios para almacenar el valor
máximo de bits definido al comienzo de la ejecución.

Tamano_Buffer: Es el tamaño que le hemos asignado al buffer. Ejemplo:
Buffer de tamaño 3 indicaría que tendríamos disponibles tres intervalos de
tiempo hasta que el buffer se vacíe.


Seguimos usando como tipo de dato para almacenar la información el unsigned
char por la misma razón que en la versión anterior.


Para almacenar la información procesada por la función de decodificación y
transformada necesitamos tener una estructura del tipo:



imagen = (TYPE ****) malloc (2 * sizeof(TYPE ***))

imagen[0] = (TYPE ***) calloc (pics, rows, cols, sizeof(TYPE))

imagen[1] = (TYPE ***) calloc (pics, rows, cols, sizeof(TYPE))


Siendo:


TYPE: Una constante de aplicación que es cargada en la compilación y que en
nuestra implementación será "unsigned int".

Pics, rows, cols: Son las dimensiones del volumen.


En conjunto esta estructura reserva memoria para un vector de volúmenes de
dos posiciones que junto con el buffer de lectura los usaremos que poder ir
encadenando lectura, decodificación, transformada inversa y representación
sin necesidad de hacer copias de la información que ha sido procesada y que
pasa de una etapa a otra.


Una representación gráfica de la estructura definida anteriormente:




















Como ahora el buffer de lectura tiene N posiciones es necesario ir
almacenando lo que se va leyendo del socket de cada una de las posiciones
del buffer, para ello nos definimos dos pequeños vectores con tantas
posiciones como elementos del buffer tengamos, en ellos almacenaremos la
cantidad de información pedida para ese GOF y la cantidad de información
que queda pendiente de recibir.


La definición de los dos vectores es la siguiente:


      Capacidad = (unsigned int *) malloc (Tamano_Buffer * sizeof(unsigned
      int))



      Pendiente = (unsigned int *)malloc (Tamano_Buffer * sizeof(unsigned
      int))



Estos vectores se van actualizando cada vez que se realiza una lectura de
información y siempre indicarán la situación actual del buffer de lectura.
Estos búferes, al igual que el de lectura son circulares, es decir, que las
posiciones van rotando cada vez que se procesa un GOF.



Representación grafica del buffer de lectura




|Posición      |1  |2  |3  |4  |n  |
|Instante 1    |   |   |   |   |   |
|Instante 2    |   |   |   |   |   |
|...           |   |   |   |   |   |
|Instante n    |   |   |   |   |   |
|Instante n+1  |   |   |   |   |   |



Para que la lectura del socket sea "no bloqueante" tenemos que usar la
instrucción select disponible en UNIX que nos permite sondear si los
dispositivos están listos para leer, escribir, etc. Tenemos que indicar en
uno de los parámetros el tiempo máximo de espera antes de que se devuelva
el control del programa, este tiempo puede ser nulo, de tal forma que
bloquee el sistema sólo el tiempo que tarde en sondear las estructuras.


Antes de realizar la lectura debemos preguntar si ha habido alguna
modificación en la estructura interna propia del select, si la ha habido es
que hay información que leer, mientras que si no, es que no hay nada que
leer (ya que en nuestra aplicación sólo controlamos los descriptores de
lectura).



Un ejemplo de lectura del socket:



      if (FD_ISSET ( sock_aux, fds ) ) {

                  nbytes=read(sock_aux,buf,bytes);

           }





      Conclusiones


En términos generales esta implementación es la que mejor se comporta de
todas las anteriores, es bastante estable frente a problemas de red como
pueden ser los altibajos de la tasa de transferencia tan comunes en
Internet, gracias a que disponemos de un buffer que hace de "colchón".



   Ahora aprovechamos toda la información que nos llega por lo que se mejora
la visualización. También se ha eliminado la "congelación" de la imagen
producida al realizar una lectura y no haber disponible información.


El único problema que nos queda por resolver es la perdida de la sincronía
que se produce cuando se tarda más tiempo que el disponible en decodificar
y en realizar la transformada.



Quinta Implementación.


Esta versión del cliente de video progresivo se basa en la anterior ya que
es la más completa de todas y la que mejores resultados hemos obtenido.


Hasta ahora la función de decodificación y transformada inversa se
realizaba sobre el total de información recibida del canal, es decir, que
si en un instante dado teníamos X bytes de información sobre un GOF, se
pasaba a proceso X bytes y hasta que no se terminase de procesar
completamente esa cantidad de información no se pasaba el resultado a la
fase de pintado o representación.


En un caso normal este tiempo es inferior a lo que se tarda en representar
un volumen, pero existen casos donde esto no se cumple, por ejemplo si
nuestra CPU no es muy potente y le pedimos que procese mucha información en
un cierto tiempo, es muy posible que no pueda, aquí es donde empiezan
nuestros problemas, otro caso sería cuando la CPU está procesando una
cantidad de información y todo se comporta de una forma estable y un
programa externo requiere de computación (cosa normal en sistemas
multiproceso), la CPU tiene que atender a varios programas que se están
ejecutando en paralelo y entonces su capacidad de proceso deja de ser
suficiente para procesar el volumen de información.


Estudiando el comportamiento de los algoritmos de decodificación y
transformada obtenemos:


El algoritmo que realiza la transforma inversa wavelet 3D es un proceso que
no podemos abandonar (en teoría sí que se puede abandonar, pero los
resultados que se obtienen no son los adecuados para este proyecto) sin que
se haya procesado completamente todo el volumen.





   El algoritmo que realiza la decodificación usando SPIHT3D es un proceso
que, podemos abandonar en un instante dado y afectaría a la cantidad de
información que le haya dado tiempo a decodificar, pero el volumen obtenido
es válido para que se le realice la transformada inversa.



Partiendo de estas premisas y dado que en nuestra implementación estas
funciones van seguidas una detrás de la otra, se nos plantea el problema de
saber cuando tiene que abandonar la tarea que esté realizando la función de
decodificación, ya que no es fácil de medir y que además no es exacto ya
que depende de muchos factores externos a nuestro control. Si le indicamos
que abandone con mucha prontitud, se decodificarán pocos bytes afectando al
visionado y si lo hacemos demasiado tarde no solucionamos el problema,
además seguimos sin asegurar que la transformada inversa se complete en el
tiempo necesario.



Una solución a este problema es invertir las fases de procesamiento, es
decir, sabiendo que la fase de transformada tiene que ser completa y la
fase de decodificación puede dejarse incompleta, hacer que primero se
procese la transformada de forma completa y posteriormente la
decodificación con el tiempo restante y cuando este tiempo esté a punto de
terminar, abandonar la función de decodificación.


La representación gráfica del sistema actual sería:



|Tiempo      |Procesos realizados en ese         |
|            |instante                           |
|Instante 1  |Lectura GOF1                       |
|            |Decodificación (Negro)             |
|            |Transformada (Negro)               |
|            |Representación (Negro)             |
|Instante 2  |Lectura GOF2                       |
|            |Decodificación (GOF1)              |
|            |Transformada (GOF1)                |
|            |Representación (Negro)             |
|Instante 3  |Lectura GOF3                       |
|            |Decodificación (GOF2)              |
|            |Transformada (GOF2)                |
|            |Representación (GOF1)              |
|Instante 4  |Lectura GOF4                       |
|            |Decodificación (GOF3)              |
|            |Transformada (GOF3)                |
|            |Representación (GOF2)              |
|Instante 5  |Lectura GOF5                       |
|            |Decodificación (GOF4)              |
|            |Transformada (GOF4)                |
|            |Representación (GOF3)              |
|Instante 6  |Lectura GOF6                       |
|            |Decodificación (GOF5)              |
|            |Transformada (GOF5)                |
|            |Representación (GOF4)              |
|...         |...                                |
|Instante n  |Lectura GOFn                       |
|            |Decodificación (GOFn-1)            |
|            |Transformada (GOFn-1)              |
|            |Representación (GOFn-2)            |


   La representación gráfica del sistema con las etapas invertidas sería:




|Tiempo      |Procesos realizados en ese         |
|            |instante                           |
|Instante 1  |Lectura GOF1                       |
|            |Transformada (Negro)               |
|            |Decodificación (Negro)             |
|            |Representación (Negro)             |
|Instante 2  |Lectura GOF2                       |
|            |Transformada (Negro)               |
|            |Decodificación (GOF1)              |
|            |Representación (Negro)             |
|Instante 3  |Lectura GOF3                       |
|            |Transformada (GOF1)                |
|            |Decodificación (GOF2)              |
|            |Representación (Negro)             |
|Instante 4  |Lectura GOF4                       |
|            |Transformada (GOF2)                |
|            |Decodificación (GOF3)              |
|            |Representación (GOF1)              |
|Instante 5  |Lectura GOF5                       |
|            |Transformada (GOF3)                |
|            |Decodificación (GOF4)              |
|            |Representación (GOF2)              |
|Instante 6  |Lectura GOF6                       |
|            |Transformada (GOF4)                |
|            |Decodificación (GOF5)              |
|            |Representación (GOF3)              |
|...         |...                                |
|Instante n  |Lectura GOFn                       |
|            |Transformada (GOFn-2)              |
|            |Decodificación (GOFn-1)            |
|            |Representación (GOFn-3)            |



Si nos fijamos, nos damos cuenta que, con esta implementación tendremos una
latencia de tres instantes de tiempo desde que comenzamos a recibir
información del primer GOF hasta que se visualiza. Este es el único efecto
negativo que tiene este diseño.


En la función de decodificación tenemos que indicarle de alguna forma, que
en un instante dado, abandone lo que está procesando y que termine, para
este fin usamos una variable de tipo entero que se comporta como un flag
booleano.


El tiempo necesario para abandonar la función es corto, pero no es
inmediato, esto es debido a la estructura del algoritmo por lo tanto
debemos tenerlo en cuenta.


El lugar idóneo para activar el flag es dentro de la interrupción ya que en
todo momento sabemos en qué fotograma de la visualización nos encontramos y
podemos activarlo en el momento adecuado. Este flag se activa un número n
de interrupción antes del final, este valor n no puede ser ni muy pequeño
ni muy grande, así que es un valor que está definido al comienzo de la
ejecución. Si el valor es muy grande le estamos diciendo que abandone muy
pronto con lo que se decodificará poca información perdiendo calidad en la
imagen, si es muy pequeño entonces puede ser, que no solucionemos el
problema de la congelación de la imagen, debemos encontrar un punto de
equilibrio, pero está en función de muchos factores (programas externos,
fotogramas del video, etc.), un valor idóneo para la CPU donde se han
realizado las simulaciones es 2.



La representación gráfica de la implementación:





































Conclusiones


Con este cambio en la ejecución del cuerpo del cliente se ha mejorado la
resistencia del visor ante factores internos o externos que afecten a la
capacidad de procesamiento de la CPU.



   Ahora que todos los problemas han sido solucionados o suavizados, vamos a
implementar dos mejoras que hacen que el software se adapte a la capacidad
de la red y a la capacidad de la CPU.




Mejoras sobre la Implementación.


Las dos mejoras que se van a realizar sobre la  última  versión  del  núcleo
del visor son necesarias para conseguir que el software se adapte a la  tasa
de red  y  para  conseguir  que  la  cantidad  de  información  que  pase  a
procesamiento vaya en función de la capacidad de procesamiento  de  la  CPU,
en cada instante.


Para obtener en cada momento la tasa  de  red  existente  y  que  por  tanto
condicionará la información que pediremos al servidor, necesitamos  realizar
un control sobre la cantidad de información pedida en el último  instante  y
el tiempo que se tarda en recibir dicha información. Cuando  ese  tiempo  es
inferior al tiempo de procesamiento, nos  indica  que  la  tasa  de  red  ha
aumentado,  en  caso  contrario  ha  disminuido.   En   nuestra   aplicación
controlamos en qué número de interrupción  hemos  recibido  la  cantidad  de
información pedida  en  el  instante  anterior.  Si  aún  nos  queda  alguna
interrupción por ejecutarse quiere decir, que la tasa de red  aumentó  y  la
nueva tasa de red será una proporción, en caso contrario habrá disminuido  y
la nueva tasa de red será la cantidad leída.


Para  conseguir  obtener  una  medida  de  la  tasa  de  CPU  pensamos  que,
controlando la cantidad de información que la función de decodificación  era
capaz de procesar, obtendríamos una buena aproximación.


Para ello nos hizo falta  modificar  dicha  función  para  conocer  en  cada
instante el número de bytes que procesaba, con esta medida y el  control  de
las interrupciones hicimos una estimación similar  a  la  conseguida  en  el
caso de la tasa de red.


Además a  la  hora  de  realizar  la  petición  de  una  nueva  cantidad  de
información al servidor habría que tener en cuenta los cálculos realizados.


Para calcular la nueva cantidad utilizamos la siguiente formula:


Tasa de red = ( Tasa de red + (1 - () Tasa de red actual


Donde:


Tasa de red: Es la tasa de red histórica.

Tasa de red actual: Es la tasa de red calculada en el instante  que  estamos
procesando.

(: Un valor que indica el peso que tiene la tasa histórica  con  respecto  a
la tasa actual.


Además de la tasa de red, hay que tener en cuenta la tasa de  CPU  obtenida,
ya que afecta de forma indirecta a la tasa de red y viceversa.


La nueva cantidad de información pedida al servidor será el mínimo de  estos
dos valores. Esto es lógico ya que si uno de los dos valores es superior  al
otro entonces estaríamos sobrecargando el inferior con más tarea de  la  que
puede realizar.


Un ejemplo que es demostrativo, por sí  solo,  es  cuando  la  ejecución  se
realiza sobre una red local, en este escenario la tasa de  red  que  podemos
obtener es muy superior a la cantidad de información que casi cualquier  CPU
pueda procesar, por lo tanto para qué enviar  una  cantidad  X  de  bytes  a
procesamiento si la CPU va a procesar una pequeña parte de ese  X,  enviamos
menos y de esa forma no la estamos sobrecargando  con  trabajo  innecesario.
En caso contrario, el escenario es la transmisión sobre  un  modem  de  56k,
aquí  la  tasa  de  red  es  pequeña  en  comparación  con  la  cantidad  de
información  que  puede  procesar  una  CPU  media,  por  lo  tanto  es  una
equivocación sobrecargar la red si no nos va a responder a tiempo.



Por último, incluso controlando la tasa de CPU y de red en cada instante,
nunca estamos seguros de que toda la fase de procesamiento (transformada
inversa y decodificación) acaben a tiempo para el siguiente GOF, en este
caso se produce una espera en la reproducción lo más pequeña posible para
que la sincronización permanezca.


Con estas dos mejoras implementadas damos por completo el núcleo del
cliente de video progresivo, este núcleo se comporta muy bien frente a todo
tipo de escenarios produciendo que sea ejecutable en la mayoría de
configuraciones, digo en la mayoría de los casos porque existe uno que no
hemos tratado en este proyecto y es cuando la máquina donde se va ha
ejecutar el visor no tiene la suficiente capacidad para procesar la
transformada inversa del volumen de los GOF del video, esto debería
producir "congelaciones" en la visualización de forma continuada, aunque no
hemos podido estudiar el caso en cuestión, suponemos que ese será el
resultado.




Descripción de la Interfaz de la Aplicación.


Una vez que el núcleo del cliente estuvo terminado y probado que todo se
comportase de forma correcta tuvimos que empezar a realizar la interfaz
para el cliente.


Dada las nuevas tendencias en la programación en UNIX pensamos que usar un
entorno gráfico tipo GTK (Gnome) ó el equivalente de KDE sería una buena
elección. Al realizar una primera prueba sobre el entorno GTK nuestro
resultado fue otra vez desalentador, el motivo, que dichos entornos usan de
forma intrínseca los threads de UNIX y en nuestro núcleo producía los
efectos explicados anteriormente. Esta prueba además de inútil nos hizo
perder mucho tiempo estudiando la forma de integración.


Como otra opción teníamos el diseñar la interfaz a bajo nivel usando las
API de X Window que reciben el nombre de Xlib. Estas bibliotecas te
permiten tener toda la libertad posible para diseñar cualquier tipo de
interfaz pero con el inconveniente, de que todo hay que programarlo. Los
entornos X de UNIX están basados en estas librerías, otra ventaja, es que
la aplicación sería portable a la mayoría de  los sistemas UNIX.




Introducción a X Window.


X Window es un sistema de ventanas desarrollado a mediados de los 80 y que
se ha convertido en el estándar de los sistemas UNIX y, en particular, de
Linux.


X Window es un sistema orientado a cliente/servidor, donde el servidor
reside en cualquiera de los ordenadores de la red, y el cliente puede ser
el mismo host que el servidor o cualquier otro host(u hosts) de la red. El
cliente se dedica a hacer peticiones al servidor, que es quien maneja el
display o los dispositivos de entrada. Estos programas clientes son:


Aplicaciones: Son los programas en sí mismos: procesadores de textos, hojas
de calculo, juegos, etc. Existen múltiples maneras de generar las
aplicaciones (Gtk, Xlib, Imlib, etc), pero nosotros utilizaremos las
llamadas a Xlib.

Windows Managers: Es el gestor de ventanas, un programa cliente con algunos
privilegios extra que se desarrolla para que gestione el interfaz o GUI
comunicándose con el servidor X y que es el encargado de la forma en que se
presentan las ventanas en pantalla, de dar facilidades con menús de
configuración del sistema, barras de tareas, etc.


En cambio, el servidor X es el programa que proporciona las primitivas a
las aplicaciones, con las que se comunica por medio de sockets. Los
programas son ejecutados en la máquina servidora y se visualizan en la
máquina cliente. El servidor controla el display ejecutando las peticiones
de los clientes, generando los eventos y notificándoselos a las
aplicaciones.


Esta comunicación entre cliente y servidor se realiza mediante 4 mensajes
(request, reply, event y error) con un formato determinado, protocolo
denominado Protocolo X:


Request: Mensaje de petición de servicio enviado del cliente al servidor,
tales como peticiones de creación, redimensionado o movimiento de una
ventana, de dibujo de primitivas gráficas como pixels o líneas, etc. Estos
mensajes son procesados en el mismo orden con que son enviados  a un buffer
que proporcionan las Xlib y que se vaciará con el consecuente envío al
servidor cuando sea necesario (cuando esté lleno, cuando se requiera una
respuesta por parte del servidor, cuando sea desactivado (XSync) o cuando
sea vaciado (Xflush)).



   Reply: posible mensaje de respuesta esperado (si es necesario) por el
cliente proveniente del servidor, como la respuesta a una petición de
tamaño de pantalla, ancho de la fuente actual del texto o posición de
cualquier ventana.


Event: es un mensaje enviado del servidor al cliente cuando ocurre un
evento en el host que constituye el servidor (pulsación de teclado o botón
del mouse, movimiento de una ventana, etc). Cada uno de estos eventos son
enviados a los clientes que especificaron qué tipo de eventos querían
recibir, de manera que es posible que nuestra aplicación cliente no reciba
ningún mensaje del teclado si, por ejemplo, todo su manejo se realiza con
el ratón y así lo hemos especificado, con el consiguiente ahorro de
procesamiento por nuestra parte.


Error: es enviado por el servidor al cliente en caso de error.


Lo primero que debemos señalar es que X Window es un sistema orientado a
displays. Es decir, hemos de tener claro es qué display se está trabajando,
ya que recordemos que X Window es un entorno de red, donde el display se
puede encontrar en cualquier máquina. El display puede definirse como una o
más pantallas y sus dispositivos de entrada (teclado y ratón). En principio
sólo se suele disponer de un display (display 0, ya que estos van
numerados) y una pantalla (la 0).


Los displays son sistemas de visualización de mapas de bits (también
llamados bitmaps). Un mapa de bits es una imagen formada por pixels (puntos
con un valor numérico asociado que representan un color en nuestro
display), y el display es un dispositivo manejador de estos bloques de
gráficos (formados por las unidades elementales de los gráficos 2D, los
pixels).


Cada posición en pantalla puede determinarse a partir de 2 valores
numéricos que representan las coordenadas del píxel. (por ejemplo, (0,0) es
la esquina superior izquierda de la pantalla y (1023,767) sería la esquina
inferior derecha en un display de una anchura y altura de 1024x768 pixels
de resolución.


Una ventana es un recuadro o área generalmente cuadrada en la pantalla
donde generalmente cada programa produce su salida (de texto, gráfica, etc)
Gracias al Window Manager las ventanas pueden ser movidas, se pueden
cerrar, modificar de tamaño, etc. La ventana activa en cada momento (sobre
la que recae el foco del usuario) se diferencia de las demás porque la
barra de título de la misma tiene diferente color o forma que las que no
están activas.


Los eventos son mensajes (de tipo event) enviados desde el servidor al
cliente para avisar de cambios en el sistema o de acciones del usuario o
programa del cliente, como pulsaciones o liberaciones de teclas. Este tipo
de eventos son generados por hardware, pero también es posible generar
eventos por medio del software, como cuando el usuario modifica el tamaño
de una ventana o la mueve. Xlib guarda los eventos que va recibiendo desde
el servidor en una cola de la que los recoge el programa en una sección de
código llamada bucle de mensajes. Por otra parte, no todos los eventos son
enviados al cliente, sino sólo aquellos que el cliente especificó que se le
deben enviar.


Los recursos son objetos almacenados en forma de información de diverso
tipo en los servidores (recursos del servidor), identificados por lo que se
conoce como identificadores de recursos. Ejemplos de recursos son las
fuentes de letra, los mapas de bits (gráficos, iconos o pixmaps), etc. La
ventaja de que sea el servidor quien almacena los recursos es que el
cliente no debe preocuparse del almacenamiento de los mismos, ni tampoco
deben ser enviados por la red, ya que el programa se ejecuta en la máquina
servidora, con lo que el tamaño de los clientes en memoria es menor y no
necesitan estar obteniendo continuamente información de la red de
transmisión. Cuando el cliente le pide al servidor que cree una ventana,
éste le devuelve al cliente un entero identificador de esa ventana, valor
numérico que utilizará el cliente después para referir cualquier operación
(de dibujo, por ejemplo) sobre dicha ventana. Por otra parte, las
propiedades de un recurso indican las características concretas de un
recurso, de tal modo que al hablar de las propiedades de una ventana se
puede hablar de su anchura, altura, posición o color de fondo.


Un pixmap es un rectángulo donde se dibujan gráficos de manera transparente
a la pantalla (el usuario no ve el dibujo), es decir: es un recurso de
almancenaje de mapas de bits, de tal modo que luego puedan ser trazados
sobre las ventanas. Sobre el tema de los gráficos también disponemos de los
contextos de gráficos (GC, Graphics Context), que son bloques en los que se
almacena la información sobre la manera de representar un determinado
gráfico. Los identificadores de GC nos permiten especificar la manera con
que representar una determinada primitiva gráfica (línea, pixels, etc.).


Por otra parte, un cursor es el símbolo gráfico que muestra la posición
actual del dispositivo apuntador, así como la información de su tamaño y
forma, y una fuente es un recurso que almacena información de cada fuente
de letras (con la que modificar el tipo de letra de nuestra aplicación
seleccionando para la misma un nuevo identificador de fuente.



Diseño de la interfaz.


Tomando como "referencia" una conocida aplicación de Windows hicimos una
interfaz adaptada a las acciones que teníamos pensado que hiciera, para
ello realizamos una serie de imágenes jpeg con las partes de la interfaz,
en conjunto tenía que ser parecido a las aplicaciones que usan skins
(pieles) para cambiar  su aspecto gráfico, en nuestro caso es bastante
similar.



Una vez que ya teníamos las imágenes que formarían parte de nuestra
interfaz la integramos de forma independiente en un programa aparte y le
dimos funcionalidad a la mayor parte de las opciones.



Las imágenes que forman nuestra interfaz son las siguientes:



|[pic]                                                                 |
|                                                                      |


  Esta imagen será la base de nuestra aplicación, como se puede observar a
     simple vista tendrá opciones de reproducción, parada, incrementar y
    disminuir la calidad de la visualización y otras opciones que no son
                       visibles sólo con esta imagen.






|[pic]                                                                 |
|                                                                      |
|[pic]                                                                 |
|                                                                      |


  Estas imágenes servirán para indicar al usuario si está posicionado o no
   sobre la opción de reproducción. La parte negra del botón se iluminará
              cuando el puntero del ratón se posicione encima.





|[pic]                                                                 |
|                                                                      |
|[pic]                                                                 |
|                                                                      |


 Estas imágenes servirán para indicar al usuario que está posicionado sobre
                             el botón de parada.


|[pic]                                                                 |
|                                                                      |
|[pic]                                                                 |
|                                                                      |


 Estas imágenes indicarán al usuario que está posicionado sobre la opción de
                          salida de la aplicación.


|[pic]                                                                 |
|                                                                      |
|[pic]                                                                 |
|                                                                      |
|[pic]                                                                 |
|                                                                      |
|[pic]                                                                 |
|                                                                      |


  Estas imágenes indicarán al usuario que está posicionado en la opción que
   le permite aumentar o disminuir la calidad de visualización del video.



|[pic]                                                                 |
|                                                                      |
|[pic]                                                                 |
|                                                                      |


     Estas barras se utilizarán en la interfaz para simular una barra de
     desplazamiento que hará que la aplicación se comporte de una forma
      especial, más adelante detallaremos su funcionamiento y utilidad.





|[pic]                                                                 |
|                                                                      |
|[pic]                                                                 |
|                                                                      |
|[pic]                                                                 |
|                                                                      |
|[pic]                                                                 |
|                                                                      |

Estas imágenes servirán para simular el buffer de lectura que implementa el
núcleo del visor, los distintos colores de las barras indicarán condiciones
que se dan en la reproducción del video, más adelante se explicarán en
detalle.


Además de las imágenes anteriores que servirán para interactuar con el
usuario se informará en la interfaz mediante texto de la evolución de la
visualización, así como de los parámetros iniciales, etc.


Estas imágenes deben estar ubicadas dentro de una carpeta llamada "skin" a
la misma altura del ejecutable de la aplicación.


Para el diseño de las imágenes se ha usado un programa de diseño gráfico
para la plataforma Windows, el software en cuestión es "Adobe Photoshop
5.0", este programa nos permite realizar cualquier tipo de tratamiento
sobre una imagen, en nuestro caso nos hizo falta rediseñar parte de la
interfaz, limpiarla, redondear los bordes, etc.



Programación de la interfaz.


Después de estudiar la forma de programar usando las APIs de las X Window y
habiendo comprendido su funcionamiento, realizamos un programa de ejemplo
para diseñar nuestra interfaz, junto con la interacción del usuario, salvo
que no hacíamos ninguna acción al seleccionar cualquier opción de la
interfaz.


Una estructura básica de cualquier programa en X Window sería el siguiente:



      Programa:

      {

            Inicialización();

      SeleccionaEventos();



            Repetir Espera_Evento

            {

                  Si llega Pulsación_de_teclado:

                  {

                       Codigo que gestiona teclado;

                  }

                  Si llega Pulsción_de_ratón:

                  {

                       Código que gestiona ratón;

                  }

                  Etc...

                  Resto de eventos: nada();

            }

            liberación();

      }







      En la inicialización se suelen realizar las siguientes operaciones:


Apertura del display: Mediante XOpenDisplay() se abrirá el display deseado,
normalmente el display 0.

Creacción de una (o más) ventanas de trabajo: Utilizando funciones
específicas para ello (XCreateSimpleWindow() o XCreateWindow()), creamos la
ventana principal de nuestra aplicación.

Mapeado de la ventana: Con el fin de que la ventana sea visible, la
mapeamos.



En la selección de eventos se suele realizar las siguiente operación:


Indicar al servidor que tipo de eventos tiene que detectar, clasificar e
identificar para que la aplicación defina su comportamiento ante cada
evento. Para ello hay que estudiar bien los eventos y seleccionar sólo los
necesarios, esto evita la sobrecarga de operaciones en el servidor.





      Para nuestro problema la estructura es bastante similar a la anterior,
tendremos una inicialización de variables, entre ellas el Display, la
ventana, el GC (contexto gráfico), los pixmaps y las imágenes jpeg de la
interfaz en estructuras adecuadas para el caso.


Una vez cargadas seleccionamos los eventos para los que nuestra aplicación
debe responder, los eventos configurados son:


ExposureMask: Al seleccionar esta máscara se recibirán los eventos de tipo
Expose, que indican que una parte rectangular de la ventana se ha hecho
visible, como por ejemplo en el caso de que una ventana de otra aplicación
solapara en parte a nuestra ventana y de repente fuera cerrada o movida,
con lo que el servidor se ve en la obligación de avisarnos de esta
circunstancia para que nuestro programa sepa que puede dibujar en dicho
área. Si más de una zona se liberara simultáneamente, se generará un evento
por cada zona rectangular que se haga visible, lo que nos permitirá
redibujar cada una de estas zonas con los datos gráficos que deban contener
y que antes no eran necesarios al estar tapados por otra ventana.





ButtonPressMask: Nos avisa de pulsaciones del botón del mouse mediante un
evento del tipo ButtonPress. Es decir, si seleccionamos el evento
ButtonPressMask el servidor nos enviará los mensajes ButtonPress pertinente
a la ventana especificada.


PointerMotionMask: Esta máscara hace que se reciba un evento MotionNotify
cuando se produzca cualquier movimiento del puntero del ratón (sin
necesitar que el botón sea pulsado).


Existen una serie de eventos que siempre están seleccionados, que son los
siguientes: MappingNotify, ClientMessage, SelectionRequest, SelectionNotify
y SelectionClear.


Dependiendo del tipo de evento que se desencadene realizamos unas
operaciones u otras. Dichas operaciones son:


Evento Expose: En este evento realizamos las operaciones de repintado de la
pantalla con los datos almacenados durante la ejecución. Ejemplo imaginemos
que estamos reproduciendo un video y una ventana externa solapa nuestra
ventana, al moverla y volver a dejarla visible se genera este evento y por
lo tanto debemos repintar la pantalla con los datos actuales.


Evento ButtonPress: En este evento comprobamos si hemos pulsado con el
ratón sobre ciertas partes de la aplicación, para controlar pulsaciones de
botones, etc. Es el evento que genera las acciones en nuestra aplicación.


Evento MotionNotify: En este evento controlamos si el puntero del ratón ha
pasado sobre alguna parte de la ventana, lo utilizamos para iluminar los
botones de la aplicación cuando pasamos el puntero del ratón sobre ellos.



Otra de las tareas a realizar es la carga de las imágenes sobre una
estructura adecuada para nuestro programa, dicha estructura esta formada
por:




      struct est_imagen

      {

        int x,y,anchura,altura,xmin,xmax,ymin,ymax;

        Pixmap bitmap;

        Pixmap bitmap2;

        int origenx;

        int origeny;

        int desplazamiento;

      };


Donde:


X,Y : Posición inicial de la imagen en la ventana.

Anchura, Altura: Indican la altura y la anchura de la imagen.

Xmin, Ymin, Xmax, Ymax: Indican el contorno de la imagen y que se utilizará
para indicar si ha sido pulsado, seleccionado, etc.

Bitmap, Bitmap2: En estas variables se cargarán los mapas de bits en si, es
decir las imágenes jpeg, tenemos dos, porque normalmente cargamos la imagen
activada y la desactivada.

Origenx, Origeny: Se utiliza para cargar varias imágenes una detrás de
otra, por ejemplo el buffer, o la barra de desplazamiento.

Desplazamiento: Indica el desplazamiento entre imagen e imagen, se usa para
el buffer y la barra de desplazamiento.


Existen imágenes que no usan todos los campos, pero para tener una sola
estructura que englobase a todas, se utilizó una general.



Una vez que la interfaz se comportaba de forma adecuada sobre un programa
"vacío", es decir que no realizaba nada, salvo indicar los eventos que se
producían, pasamos a la integración del núcleo del visor con la interfaz.
Durante la integración se añadieron detalles a la interfaz, pero se fueron
haciendo sobre el software integrado.






Integración de la interfaz y el núcleo del visor.



Para poder integrar la interfaz y el núcleo del visor utilizamos funciones
de programación de sistemas: creación de procesos mediante fork(),
utilización de memoria compartida para la comunicación entre ambos. El
grueso de la aplicación estaba dividida en dos procesos, uno que controlaba
la interfaz junto con el repintado, la generación de eventos, etc, y otro
proceso, que era donde se hacía la lectura de información sobre el socket,
la decodificación, transformada inversa y la visualización de GOF, ambos
procesos se comunicaban mediante una estructura almacenada en un área de
memoria compartida.


La interfaz modifica su aspecto por dos motivos, por acciones del usuario,
que estaban controladas por el proceso de la interfaz ó por motivos propios
de la reproducción del video, en cuyo caso estarían controlados por el
proceso correspondiente.


Una imagen de la interfaz en ejecución:



La representación gráfica del cuerpo de la implementación:









































La estructura compartida por ambos procesos y por tanto alojada en memoria
compartida tiene la siguiente definición:


      struct estructura {

        int bpgmemoria;

        int reloj;

        int bpgmax;

        int bpgreal;

        int stop;

        int salir;

        int cerrojo;

        float alfa;

        float porcentaje;

        int pics;

        int picscpu;

        int picscpuleft;

        int bpgred;

        int bpgdec;

        int causante;

        int swcpu;

      };



Donde :


bpgmemoria: Esta variable se usa para almacenar los BPG máximos permitidos
durante la ejecución de la aplicación. Esto es debido a que la reserva de
memoria está en función de esta variable.

reloj: Variable usada para indicar en que GOF de ejecución nos encontramos,
además de alterar el tiempo en la interfaz, similar a un reloj digital.

bpgmax: En esta variable almacenamos los BPG máximos actuales para un
instante en concreto. Nunca supera a la variable bpgmemoria.

bpgreal: Indican los bits que se pasan a la fase de procesamiento y que por
tanto repercute en la calidad de la imagen.

stop: Indica si se ha pulsado o no el botón de parada.

salir: Indica si se ha pulsado el botón de salida, esta variable activada
hace que la aplicación termine.

cerrojo: Variable de condición utilizada para los cerrojos.

alfa: Variable utilizada para almacenar el valor de ( necesaria para el
cálculo de la tasa de red.

porcentaje: Indica el porcentaje seleccionado en la barra de
desplazamiento.

pics: indica en qué interrupción se ha terminado de leer la cantidad de
información pedida al servidor en el instante anterior.

picscpu: Indica en qué interrupción se ha terminado el proceso de
decodificación. Se utiliza para calcular la tasa de CPU.

picscpuleft: Indica cuantas interrupciones quedan por ejecutarse una vez
que se termina el proceso de decodificación.

bpgred: Indica la cantidad de bytes que se han leído durante "pics"
interrupciones. Se utiliza para calcular la tasa de red.

bpgdec: En esta variable es donde se almacenan los bytes reales que se
procesan en la fase de decodificación. Se utiliza para calcular la tasa de
CPU.

causante: Almacena un número que indica quién es el responsable de la
cantidad de información pedida al servidor ya que esta tasa se calcula del
mínimo entre la tasa de red y la de CPU.

Swcpu: Se utiliza como variable de condición para saber en que instante ha
terminado de procesar la función de decodificación.


La integración entre el núcleo del visor y la interfaz desarrollada usando
la biblioteca Xlib y el rendimiento es muy bueno.



Funcionamiento de la Interfaz.


En apartados anteriores hemos hecho referencia a opciones de la interfaz o
a variables que hacen una cosa u otra, en este apartado vamos a explicar el
funcionamiento de la interfaz y la información que nos ofrece como usuario
de la misma.


La interfaz está dividida en 4 partes diferenciadas:


Pantalla Principal: En esta zona se muestra información relativa a la
conexión (máquina y puerto a donde estamos conectados), el nombre del video
que estamos reproduciendo, la máxima cantidad de información a la que
podemos reproducir y la cantidad de información del siguiente GOF que vamos
a procesar.


Buffer lectura: Esta situado a la derecha de la interfaz y está formado por
unas barras de colores, el color indica el estado de cada posición del
buffer.


Si el color es verde, indica que esa posición tiene información para ser
procesada cuando sea su turno.

Si el color es gris indica que esa posición del buffer está vacía ó se está
llenando, pero que aún no está completa.

Luego existen dos colores más (azul y rojo), estos colores solo se
encienden en la posición más alta del buffer e indican quién es el
responsable de la cantidad de información pedida al servidor siempre que no
se haya podido recibir o procesar la cantidad de información estimada para
este intervalo.

Además en cada posición del buffer tiene un número que indica la cantidad
de kbits que hay almacenado en dicha posición.






   Marcador tiempo: Está situado debajo de la pantalla principal a cada
segundo que cambia se procesa un GOF, así que realmente no es un
temporizador de horas, minutos y segundos sino que es un "temporizador de
GOF".


Cuadro de mandos: El cuadro de mandos es la forma que tiene el usuario de
comunicarse con la interfaz, existen diferentes opciones a realizar:


Play: Este botón se utiliza para empezar a reproducir el video, también se
usará cuando el video esté parado y queramos ponerlo en marcha.

Stop: Se utiliza para parar la imagen de la reproducción, el núcleo sigue
recibiendo información del socket.

Mas y menos: Estos botones se utilizan para indicarle al núcleo cual es el
tope máximo de bytes que podemos recibir, procesar, etc. de un GOF, se
utiliza para comprobar la progresividad de la reproducción. Con estos
botones aumentamos ó disminuimos ese tope.

Salida: Este botón sirve para abandonar la aplicación, es necesario pulsar
esta opción ya que así la aplicación se abandona de forma adecuada,
descargando memoria, cerrando el Display, los sockets, etc.

Barra de desplazamiento: Esta barra se utiliza para forzar al núcleo a que
pida un porcentaje de la información calculada para el siguiente instante,
se utiliza para ver la progresividad de la reproducción. Cada posición de
la barra indica un porcentaje de dicha cantidad, estos porcentajes son
(20,40,60,80,100,120,140,160,180,200) siempre que no sobrepasen la tasa
calculada se pedirá el porcentaje indicado.


Funciones de la API de UNIX utilizadas.


Durante la programación del cliente y el servidor hemos utilizado APIs o
estructuras del sistema UNIX que pueden resultar poco familiares o
desconocidas, en este apartado vamos a explicar las más importantes. Las
vamos a separar en diferentes grupos en función de su utilidad.


Tratamiento de señales y tiempos.


signal.


Para especificar qué tratamiento debe realiza un proceso al recibir una
señal, se emplea la llamada signal. Su declaración es la siguiente:


      #include <signal.h>



      void (*signal (int sig, void (*action) ())) ();


Sig es el número de la señal sobre la que queremos especificar la forma de
tratamiento.

Action es la acción que queremos que se inicie cuando se reciba la señal.
Action puede tomar tres tipos de valores:


SIF_DFL: Indica que la acción a realizar cuando se recibe la señal es la
acción por defecto asociada a la señal.

SIG_IGN: Indica que la señal se debe ignorar.

Dirección: Es la dirección de la rutina de tratamiento de la señal
(manejador suministrado por el usuario). La declaración de esta función
debe ajustarse al siguiente modelo.


                 #include <signal.h>



                 void handler (sig [, code, scp])

                 int sig, code;

                 struct sigcontext *scp;





      Cuando se recibe la señal sig, el núcleo es quien se encarga de llamar
a la rutina handler pasándole los parámetros sig, code y scp. Sig es el
número de la señal, code es una palabra que contiene información sobre el
estado del hardware en el momento de invocar a handler y scp contiene
información de contexto definida en <signal.h>. Tanto code como scp son
parámetros opcionales y dependientes de la arquitectura de nuestra máquina.


Un ejemplo de utilización de signal:


      if (signal(SIGALRM, &ProcesoVisor) == SIG_ERR) {

           fprintf(stderr,"No puedo registrar el manejador de señales para
           SIGALRM\n");

      }



Setitimer.


Esta llamada se utiliza para controlar los temporizadores que hay definidos
por cada proceso. Su declaración es la siguiente:


      #include <time.h>



      setitimer (int which, struct itimerval *value, struct itimerval
      *ovalue)


Los valores que puede tomar which son:


ITIMER_REAL: Temporizador en tiempo real.

ITIMER_VIRTUAL: Temporizador en tiempo virtual, solo contabiliza el tiempo
mientras el proceso está ejecutando y no cuando duerme.

ITIMER_PROF: Temporizador de perfilado. Se usa al crear perfiles de un
proceso.


Setitimer se utiliza para definir el valor del temporizador especificado
por which. Value es un puntero a una estructura con los nuevos valores del
temporizador y ovalue es un puntero a una estructura donde se devuelven los
antiguos valores del temporizador.


La estructura itimerval se define como sigue:


      Struct itimerval

      {

            struct timeval it_interval;

            struct timeval it_value;

      };


Siendo it_interval el intervalo del temporizador y it_value el valor actual
del temporizador.



La estructura timeval se define así:


      Struct timeval

      {

            unsigned long tv_sec;

            long tv_usec;

      };


Siendo tv_sec los segundos transcurridos desde el dia 1 de Enero de 1970 y
tv_usec indica microsegundos. Su rango está comprendido entre el 0 y
999.999.



Un ejemplo del uso de setitimer:


      /* valores de temporizacion para la señal */



      itimer.it_interval.tv_usec =i_sec;

      itimer.it_interval.tv_sec = 0;



      itimer.it_value.tv_usec = i_sec;

      itimer.it_value.tv_sec = 0;



      setitimer(ITIMER_REAL, &itimer, NULL);



Tratamiento de regiones críticas o mutex.


Entre las funciones utilizadas tenemos:



pthread_mutex_init.


Inicializa el semáforo para poder ser utilizado. POSIX define distintos
atributos que modifican el comportamiento de los semáforos. Por defecto el
mutex no utilizará ningún tipo de herencia de prioridades.


Su definición es la siguiente:


      pthread_mutex_init(pthread_mutex_t *mutex, pthread_mutexattr_t *attr)


Siendo mutex un puntero a un parámetro del tipo pthread_mutex_t, que  es  el
tipo de datos que usa la librería Pthreads para controlar  los  mutex.  Attr
es un puntero a una estructura del tipo pthread_mutexattr_t,  y  sirve  para
definir qué tipo de mutex queremos: normal, recursivo o errorcheck. Si  este
valor es NULL (recomendado), la librería le asignará un valor por defecto.

La función devuelve 0 si se pudo crear el mutex o -1 si hubo algún error.



pthread_mutex_lock.


Esta función pide el bloqueo para entrar en una RC (región crítica). Si
queremos implementar una RC, todos los threads tendrán que pedir el bloqueo
sobre el mismo semáforo. La definición es:


int pthread_mutex_lock(pthread_mutex_t *mutex)


Siendo mutex un puntero al mutex sobre el cual queremos pedir el bloqueo o
sobre el que nos bloquearemos en caso de que ya haya alguien dentro de la
RC. Como resultado, devuelve 0 si no hubo error, o diferente de 0 si lo
hubo.


pthread_mutex_unlock.


Esta es la función contraria a la anterior. Libera el bloqueo que
tuviéramos sobre un semáforo. La definición es:


      int pthread_mutex_unlock(pthread_mutex_t *mutex)


Siendo mutex el semáforo donde tenemos el bloqueo y queremos liberarlo.

Retorna 0 como resultado si no hubo error o diferente de 0 si lo hubo.


Tratamiento de procesos.


Fork.


La única forma de crear un proceso en el sistema UNIX es mediante la
llamada fork. El proceso que invoca a fork se llama proceso padre y el
proceso creado es el proceso hijo. La declaración es la siguiente:


      #include <sys/types.h>



      pid_t fork();


La llamada a fork hace que el proceso actual se duplique. A la salida de
fork, los dos procesos tienen una copia idéntica del contexto del nivel de
usuario excepto el valor de pid, que para el proceso padre toma el valor
del PID del proceso hijo  y para el proceso hijo toma el valor 0. Si la
llamada a fork falla, devolverá el valor -1 y en errno estará el código del
error producido.



Tratamiento de sockets.


Socket.


La llamada para abrir un canal bidireccional de comunicaciones es socket y
se declara como sigue:


      #include <sys/types.h>

      #include <sys/socket.h>



      int socket (int af, int type, int protocol);


Socket crea un punto terminal para conectarse a un canal y devuelve un
descriptor. El descriptor del conector devuelto se usará en llamadas
posteriores a funciones de la interfaz.


Af (address family) especifica la familia de conectores o familia de
direcciones que se desea emplear. Las distintas familias están definidas en
el fichero de cabecera <sys/socket>. Las dos familias siguientes suelen
estar presentes en todos los sistemas:


AF_UNIX: Protocolos internos UNIX. Es la familia de conectores empleada
para comunicar procesos que se ejecutan en una misma máquina.

AF_INET: Protocolos Internet. Es la familia de conectores que se comunican
mediante protocolos, tales como TCP o UDP.


El argumento type indica la semántica de la comunicación para el conector.
Puede ser:


SOCK_STREAM: Conector con un protocolo orientado a conexión.

SOCK_DGRAM: Conector con un protocolo no orientado a conexión o datagrama.


Protocol especifica el protocolo particular que se va a usar con el
conector.

Si la llamada se ejecuta satisfactoriamente, devolverá un descriptor de
fichero válido. En caso contrario, devolverá -1 y en errno estará
codificado el error producido.



Bind.


La llamada bind se utiliza para unir un conector con una dirección de red
determinada. Su declaración es la siguiente.


      #include <sys/socket.h>

      /* Para familia AF_UNIX */

      #include <sys/un.h>

      /* Para familia AF_INET */

      #include <sys/netinet.h>



      int bind (int sfd, const void *addr, int addrlen);


Cuando se crea un conector con la llamada socket, se le asigna una familia
de direcciones, pero no una dirección particular. Bind hace que el conector
cuyo descriptor es sfd se una a la dirección de conector especificada en la
estructura apuntada por addr. Addrlen indica el tamaño de la dirección.


Listen.


Cuando se abre un conector orientado a conexión, el programa servidor
indica que está disponible para recibir peticiones de conexión mediante la
llamada a listen, que se declara como sigue:


int listen (int sfd, int backlog)


La llamada a listen la suele ejecutar el proceso servidor después de las
llamadas a socket y bind. Listen habilita una cola asociada al conector
descrito por sfd. La longitud de esta cola es la especificada en el
argumento backlog. Para que la llamada a listen tenga sentido, el conector
debe ser de tipo SOCK_STREAM (orientado a conexión).


Connect.


Para que un proceso cliente inicie una conexión con un servidor a través de
un conector, es necesario que haga una llamada a connect. Esta función se
declara de la siguiente forma:


      #include <sys/socket.h>

      /* familia AF_UNIX */

      #include <sys/un.h>

      /* familia AF_INET */

      #include <sys/netinet.h>



      int connect (int sfd, const void *addr, int addrlen);


sfd es el descriptor del conector que da acceso al canal y addr es un
puntero a una estructura que contiene la dirección del conector remoto al
que queremos conectarnos. Addrlen es el tamaño en bytes de la dirección.



Accept.


Los procesos servidores van a leer peticiones de servicio mediante la
llamada accept. La declaración de esta llamada se muestra a continuación:


      #include <sys/socket.h>



      int accept (int sfd, void *addr, int *addrlen);


Esta llamada se usa con conectores orientados a conexión, como el tipo
SOCK_STREAM. El argumento sfd es un descriptor del conector creado por una
llamada previa a socket y unido a una dirección mediante bind. Accept
extrae la primera petición de conexión que hay en la cola de peticiones
pendientes creada con una llamada previa a listen. El argumento addr debe
apuntar a una estructura local con la dirección del conector. La llamada
accept rellenará esa estructura con la dirección del conector remoto que
pide la conexión. El argumento addrlen debe ser un puntero a int.


Close.


Una vez que un proceso no necesita realizar más accesos a un conector,
puede desconectarse del mismo. Para ello podemos usar la orden close. Esta
llamada va a cerrar el conector  en sus dos sentidos.



Htonl.


Función que convierte datos unsigned long del formato que maneja el
ordenador al formato que maneja la red. La definición es:


      Unsigned long htonl (unsigned long hostlong);



Ntohl.


Función que convierte datos unsigned long del formato que maneja la red al
formato que maneja el ordenador. La definición es:


      Unsigned long ntohl (unsigned long netlong);


Select.


Permite interrogar al sistema sobre el estado de varios dispositivos y
devuelve cuáles están listos para leer datos de ellos y cuáles lo están
para escribir en ellos.


La declaración de select es la siguiente:


      #include <time.h>



      int select (int nfds, int readfds, int writefds, int exceptfds, struct
      timeval *timeout);


Select examina los descriptores de fichero especificados en las máscaras de
bits readfds, writefds y exceptfds.


El significado de cada máscara es el siguiente:


Readfds representa los descriptores de los ficheros de lectura por los que
preguntamos.

Writefds representa los descriptores de los ficheros de escritura que
preguntamos.

Exceptfds representa los descriptores de los ficheros con alguna condición
especial por los que preguntamos.


Si alguna de las condiciones anteriores no nos interesa, lo indicaremos
pasándole a select el argumento 0.


Los argumentos se pasan por referencia, esto significa que select los va a
modificar de acuerdo con el estado de los ficheros que interroga.

Timeout es un puntero no nulo que indica el tiempo máximo que se va a
esperar desde que select entra en ejecución hasta que devuelve el control.
Select puede devolver el control bien porque alguno de los ficheros
interrogados cumpla los requisitos pedidos o bien porque el tiempo de
espera especificado en timeout expire. Si timeout es un puntero a NULL, la
llamada esperará a que se dé algún cambio de estado en alguno de los
ficheros interrogados.


Las máscaras de bits que codifican los números de los descriptores agrupan
32 posibles descriptores por cada numero entero. Si queremos interrogar por
ficheros con un descriptor más alto, hay que utilizar un array de enteros.
Para encapsular estos detalles, junto con select se facilita un conjunto de
4 macros para manejar variables de ese tipo.





Estas macros se definen con la siguiente interfaz:


FD_ZERO (fd_set *fdset): Pone a cero los bits de "fdset".

FD_SET (int fd, fd_set *fdset): Activa en fdset el bit correspondiente al
descriptor fd.

FD_CLEAR (int fd, fd_set *fdset): Desactiva en fdset el bit correspondiente
al descriptor fd.

FD_ISSET (int fd, fd_set *fdset): Comprueba en fdset el bit correspondiente
al descriptor fd.



Tratamiento de la memoria compartida.


Shmget.


Esta función devuelve el identificativo del segmento de memoria compartida
asociado al valor del argumento key. Su declaración es:


      #include <sys/types.h>

      #include <sys/ipc.h>

      #include <sys/shm.h>



      int shmget (key_t key, int size, int shmflg);



      key es el identificativo del área de la memoria compartida.

Size es el tamaño en bytes de la zona de memoria que queremos crear.

Shmflg es una máscara de bits que está compuesta por los siguientes
valores:


IPC_CREAT: para crear un  nuevo segmento. Si este indicador no se usa,
shmget() encontrará el segmento asociado con key, comprobará que el usuario
tenga permiso para  recibir el shmid asociado con el segmento, y se
asegurará de que el segmento no esté marcado para destrucción.

IPC_EXCL: Usado con IPC_CREAT para asegurar el fallo si el segmento ya
existe.

Mode_flags (9 bits mas bajos): Especifican los permisos otorgados al dueño,
grupo y resto del mundo.



Shmat y Shmdt.


Antes de usar una zona de memoria compartida, tenemos que asignarle un
espacio de direcciones virtuales de nuestro proceso. Esto es lo que se
conoce como unirse o atarse al segmento de memoria compartida. Una vez que
dejamos de usar un segmento de memoria, tenemos que desatarnos de él. Al
realizar esta operación, el segmento deja de estar accesible para el
proceso. Sus definiciones son:


      #include <sys/types.h>

      #include <sys/ipc.h>

      #include <sys/shm.h>


      char *shmat (int shmid, char *shmaddr, int shmflg);

      int shmdt (char *shmaddr);


Shmid es el identificador de una zona de memoria creada mediante una
llamada previa a shmget.

Shmaddr es la dirección virtual donde queremos que empiece la zona de
memoria compartida.

Shmflg es una máscara de bits que indica la forma de acceso a la memoria.


Shmctl.


Con shmct realizamos operaciones de control sobre una zona de memoria
previamente creada por una llamada a shmget. Su declaración es:


      #include <sys/types.h>

      #include <sys/ipc.h>

      #include <sys/shm.h>


      int shmctl (int shmid, int cmd, struct shmid_ds *buf)



      Shmid es un identificador válido devuelto por una llamada previa a
shmget.

Cmd indica el tipo de operación a realizar. Entre las más importantes está:


IPC_RMID: Borra del sistema la zona de memoria compartida identificada por
shmid. Si el segmento está unido a varios procesos, el borrado no se hace
efectivo hasta que todos los procesos liberen la memoria.




Tratamiento de la X Window


XOpenDisplay.


Se usa para establecer una conexión entre un programa de aplicación y un
servidor de display. Su definición es:


Display *XOpenDisplay (char *nombreDisplay)


Donde nombreDisplay es una cadena con el formato:
nombreHost:numero.numeroPantalla.


nombreHost es el nombre del host en el que reside el servidor. El numero es
el número del display, y el 'numeroPantalla' es el numero de la pantalla.


El 'nombreDisplay' puede ser NULL, en cuyo caso se usará por la cadena
almacenada en la variable de entorno DISPLAY.


XCloseDisplay.


Sirve para cerrar la conexión con el display. Su definición es la
siguiente:


      XCloseDisplay (Display *display);


Cierra la conexión con el servidor de display especificado y destruye todas
las ventanas, todos los Ids de los recursos creados por el programa.


DefaultScreen.


Devuelve el número asociado a la pantalla por defecto en referencia a un
display abierto mediante XopenDisplay. Su definición es la siguiente:


DefaultScreen (display);


Este número de pantalla se utilizará en llamadas a otras funciones, por lo
que es aconsejable que sea almacenado en una variable global.


XCreateSimpleWindow.


Se utiliza para crear una ventana asociada a un display. Su definición es
la siguiente:


      Window XcreateSimpleWindow (Display *display, Window madre, int x, int
      y, unsigned int anchura, unsigned int altura, unsigned int
      anchuraborde, unsigned long colorborde, unsigned long colorfondo);


El display especifica la conexión con el servidor. La madre especifica la
ventana madre donde se creará la ventana. Se pueden usar las macros
RootWindow o DefaultRootWindow.






XMapWindow.


Mapea la ventana especificada. Su definición es la siguiente:


      XmapWindow (Display *display, Window window);


XSelectInput


Durante la inicialización de nuestra aplicación y creación de la ventana
principal de la misma es necesario indicarle al servidor qué tipo de
eventos se desean recibir, pues puede interesarnos no recibir información
de algún tipo de evento ocurrido, mientras que otro pueda ser vital para
nuestra aplicación. Para la indicación de los eventos deseados al servidor
X se utiliza la función XselectInput y las llamadas máscaras de eventos.


La definición de la función es la siguiente:


      XselectInput (display, window, event_mask);


El argumento display es la variable que conecta nuestro cliente con el
servidor X, la variable window es el identificador de la ventana sobre la
que deseamos seleccionar los eventos que se recibirán, y event_mask es una
variable máscara. Cada bit de esta variable se refiere a un evento
concreto. Para hacer más fácil la selección de eventos se usan unas cadenas
o nombres simbólicos que identifican a los eventos.


Los principales son : ButtonPressMask, ButtonReleaseMask, KeyPressMask,
KeyReleaseMask, ButtonMotionMask, EnterWindowMask, LeaveWindowMask, etc.



XNextEvent


Recoge el siguiente evento de la cola en modo bloqueante, es decir, recoge
cualquier evento de cualquier ventana de nuestra aplicación y lo introduce
en la estructura XEvent que se le pasa como parámetro. Su definición es la
siguiente:


      XNextEvent (Display *display, XEvent *evento);


La estructura XEvent es el paquete de información que el servidor envía al
cliente cuando ocurre el evento.



XCreateGC


Un contexto gráfico o simplemente GC, es un recurso del servidor donde se
almacenan los atributos de los gráficos. Es necesario al menos un GC para
que el servidor acepte peticiones de primitivas gráficas por parte del
cliente, ya que cada petición de primitiva gráfica debe especificar el
identificador del GC que se debe usar.


Los GCs se crean y se almacenan en el servidor. Para pintar gráficos es
necesario:



   Crear un GC y obtener su ID.

Establecer los atributos del GC apropiadamente.

Enviar las peticiones de las primitivas gráficas.


La definición para crear un contexto gráfico es la siguiente:


      GC XcreateGC (Display *display, Drawable drw, unsigned long mascara,
      XGCValues *valores);


XcopyArea


La definición de esta función es la siguiente:


      XcopyArea (Display *display, drawable src, drawable dest, GC gc, int
      src_x, int src_y, unsigned int width, unsigned int height, int dest_x,
      int dest_y);


Esta función copia un área cuadrada desde el drawable src al drawable dest.
Ambos han de tener la misma profundidad de color.

La principal ventaja de trabajar con estructuras XImage consiste en que
éstas se almacenan localmente en el cliente haciendo que no tengan que
pasar por la red.