![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|
|
#1
|
||||
|
||||
|
Cita:
Mi recomendación es la siguiente: Para el tipo de aplicación que estás desarrollando deberías de utilizar algún formato de vectores como WMF (Windows Meta File). Este formato está diseñado para manejar eficientemente figuras geométricas, líneas y tipos de letra. (en algunos casos también se mezclan con mapas de bits) La ventaja de utilizar este formato es que solamente se guardan las coordenadas y parámetros importantes para la creación de cada elemento (líneas, círculos, polígonos, etc.), además cuando cambias la escala o haces un zoom obtienes un mejor resultado visualmente ya que cada figura es recalculada a partir de sus parámetros evitando que se vean pixeladas. Otra importante ventaja es que se aprovecha al máximo la resolución de la impresora. Nota: Los formatos Raster (mapas de bits) como JPG, solamente son útiles cuando se trata de fotografías o imágenes que no se pueden calcular por medio de coordenadas y parámetros sencillos; su principal desventaja es la resolución, considero que obtendrías un resultado bastante desagradable al escalar las figuras si las almacenas en JPG. Espero que el consejo te sea útil. |
|
#2
|
|||
|
|||
|
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. |
|
#3
|
|||
|
|||
|
gracias
Muchisimas gracias por responder, me doy cuenta que este pedazo del proyecto va a ser el mas pesado y tardado de todo pero eso lo hace emocionante. Me falta mucho por aprender, voy a analizar y a ir aplicando lo que me aconsejan, y les aviso.
![]() |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
|