Ajustar el tiempo de espera de la carga diferida del PUCK

[GoogleCodeExporter]

La carga de la GUI del PUCK se va difiriendo para que el usuario pueda 
interactuar con PUCK sin que se hayan creado todavía los formularios de todas 
las entidades, ya que el proceso de creación es lento.

Para ello, se usa un thread (BackgroundInitThread, línea 170 de 
GraphElementPanel.java en el momento de escribir esto) que va llamando para 
cada entidad a un método forceRealInitFromXML() (línea 92, 
GraphElementPanel.java). Este método espera 100 ms, y luego ejecuta en 
invokeLater() (y por tanto en el event dispatching thread) un Runnable que crea 
la GUI (formularios) asociada a la entidad (de ahí la necesidad de hacerlo en 
el event dispatching thread).

La combinación de esperar 100 ms y hacer un invokeLater() (que debería 
esperar a que se procesen los eventos de GUI pendientes) debería hacer en 
teoría que el proceso de carga fuera muy poco agresivo y que la GUI 
respondiese. Así es en PC's potentes, pero según informes, en máquinas de la 
generación del Pentium IV los 100 ms de retraso se quedan cortos, y para que 
el interfaz responda como debe hay que aumentar ese tiempo a 500 ms.

Poner el valor a 500 ms en general penalizaría demasiado la carga en 
ordenadores rápidos, pero tal vez habría que buscar la manera de ajustarlo 
automáticamente (¿haciendo alguna query y obteniendo la CPU? ¿Mirando la 
cantidad de elementos encolados en GUI?) y si no hay manera (cosa que parece 
posible), dejarlo a 100 por defecto pero habilitar una opción (por ejemplo en 
el fichero de configuración puck.properties) para cambiarlo al valor que se 
quiera.

Original issue reported on code.google.com by komoku on 15 Feb 2013 at 11:49

[GoogleCodeExporter]

Igual el problema es que si el thread de la GUI está ocupado en otra cosa 
mucho tiempo seguido, se acumulan varios invokeLater (dado que cada invokeLater 
no va a mirar si se ha ejecutado o no el anterior). Mirar si hay manera de 
prevenir eso.

Original comment by komoku on 15 Feb 2013 at 11:51

[GoogleCodeExporter]

Informe: con tiempo 500 la cosa va bien en la segunda carga dentro de una 
instancia de PUCK, pero no en la primera. Igual tiene que ver con que en la 
primera se están inicializando cosas en memoria, etc.

¿Podría ayudar poner en las primeras iteraciones más retardo, y después - 
con más cosas en caché, etc. - menos?

Al final, en caso de no encontrar una forma clever de ajustar la cosa 
dinámicamente, supongo que lo que habrá que hacer será profiling y ver 
realmente cuánto tiempo lleva cada iteración en esas máquinas.

Original comment by komoku on 15 Feb 2013 at 11:56

[GoogleCodeExporter]

Con 1000 ms va bien ya en primera carga.

Original comment by komoku on 15 Feb 2013 at 11:59

[GoogleCodeExporter]

This issue was closed by revision r649.

Original comment by komoku on 16 Feb 2013 at 11:13

• Changed state: Fixed