|
El Timer es inexacto. Es decir, tiene una prioridad baja en Windows, por lo que si en el momento que tiene que ejecutar el código asociado a él, windows está haciendo alguna parida, el Timer se espera, con lo que no consigo una temporización perfecta. Si lanzo la aplicación y me quedo mirando la pantalla, sin hacer nada más, ya veo como falla (y eso que es cada 320 ms ;-)). No es regular. Y si tengo a Windows ocupado de fondo, ya ni te cuento la irregularidad el joio TTimer.
Por eso me comentaron que era mejor hacerlo con hilos, porque son bastante más estables. Parece ser que Windows les da más prioridad. Al fin y al cabo, es un proceso "en segundo plano", es decir, independiente del usuario. La única interacción con el usuario es visual.
Y en cuanto a lo que necesito ejecutar, es algo un poco raro, dado los tiempos que corren. Todo se remonta a mediados de los 80, cuando me compré mi Spectrum... bueno, no me enrollo. Es un visor de pantallas de presentación del ZX Spectrum (ordenador de 8 bits de principios de los 80 para los que no lo conozcan). Estas pantallas tenían algunas partes con flash (o parpadeo). Este flash cambiaba su estado cada 320 ms.
Para implementar esto, cargo la pantalla en dos TBitmaps, uno con cada versión de la pantalla, con y sin flash, y los cargo alternativamente cada 320 ms en un TImage.
Por eso se nota mucho. Si el flash va a trompicones, no queda nada bien. Y ya ni te cuento si lo hago con dos pantallas, en dos TImages. Solo va el flash en uno de ellos. El otro (o los otros) TImages, no van ni a la de tres.
Imagino que con hilos irán todos, y sincronizados. Al fin y al cabo, cargar la pantalla me cuesta unos 35ms desde disco, dibujado incluido, por lo que imagino que el traspaso entre canvas me costará bastante menos.
Saludos del elfo
|
07-04-2005
Modo Hilado