|
Bueno lo que dice HECTOR es verdad: necesitarías unos JPEG de buena calidad y resolución. Además que un mapa de bits de alta resolución siempre va descomprimido en RAM ocupando una barbaridad de espacio.
Eso si: el resultado puede ser muy agradable en .jpeg a costa de mucha RAM y CPU con un buen algoritmo bicúbico para escalar imágenes. Podría parecer que es más fácil usar JPEG, pero no lo es y especialmente en tu caso por que lo que quieres realizar no es una composición de imágenes, es netamente vectorial.
Eso de no repintar toda el area de trabajo es tema de optimización, pero como generalmente en ese tipo de aplicación todo el tiempo se cambia de escala haciendo zoom a diestra y siniestra no vale la pena el esfuerzo de optimizar para no repintar algo que al primer click de ratón en zoom ya no será válido.
Utiliza una "superficie" para pintar en RAM (un Tbitmap de tipo device independet bitmap para que no use memoria de video en este caso eso sólo perjudicaría). Teniendo esa imagen lista repintas en pantalla cuando sea necesario. NO BORRES OBJETOS "PINTANDOLO" en otro color, directamente repinta todo menos el objeto borrado en RAM y luego lo pasas a video cuando esté listo (una llamada a repaint, si tu bitblt(), ve en la ayuda como usar este comando que es más directo, a video está en el onpaint.
Al momento de cambiar de escala tendrías que repintar toda tu superficie, pero aún así es más rápido "pintar" primero en una superficie en RAM y luego pasar el resultado final a memoria de video (pintando en el canvas de un tpaintbox por ejemplo) sólo cuando es necesario (cuando sucede el evento onpaint).
Finalmente prueba con Tbirmats a 8, 16 y 24 bits por pixel a ver cual te da menos tiempo de CPU, muy probablemente el de 8bits por baja cantidad de transferencia de memoria. Como son gráficos vectoriales (sin efectos de renderizado) 256 colores son más que suficientes.
|