Realización de un proyecto crowdsourced en Canvas - página 18
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Desgraciadamente, los intentos actuales de hacer frente al problema de la actualización retardada de la imagen guardando una matriz con una "máscara digital" no han tenido éxito. Sin embargo, tampoco es un fracaso. Sencillamente, no ha sido posible sacar una conclusión definitiva sobre la causa del retraso y encontrar una solución global al problema.
Al pensar en métodos generales para almacenar la imagen terminada en la memoria y trabajar con sus áreas, pasé por varias opciones. Las que consideraba una buena solución, tras una profunda reflexión resultaron ser poco prácticas.
Y así - mis conclusiones:
1. Si quieres guardar las imágenes en arrays, debe haber muchos arrays. Es decir, cada recurso requiere su propia matriz de memoria constante. En mi implementación, el número de lienzos (recursos, lienzos) podría ser varias veces mayor que el número de ventanas.
Le explicaré por qué:
En algunos casos este enfoque es mucho más conveniente que dibujar todos los objetos de la ventana en un lienzo, por ejemplo, cuando se desplaza una tabla en un elemento "campo de visión (VEIW BOX)", es conveniente colocar los elementos de la tabla en un lienzo separado dentro de este elemento y desplazar este lienzo como un objeto completo. La velocidad de desplazamiento es más rápida. Por lo tanto, cada elemento de este tipo lleva un kanvas separado dentro de él. De lo contrario, tendrá que sobrescribir toda la imagen de la ventana guardada en la memoria. Esto le llevará definitivamente mucho más tiempo.
Además, es bastante incómodo dibujar todas las ventanas en un lienzo, ¿cómo moverlas entonces? Supongamos que creamos un "mega" lienzo para toda el área del gráfico. Todas nuestras ventanas se dibujarán en él. Después de dibujar las ventanas en el kanvas, intentaremos moverlas, pero para ello tendremos que reescribir toda la imagen de este único "mega" kanvas. La imagen es muy grande y la cantidad de valores reescritos será enorme. Aunque la imagen se guarde, tendremos que sobrescribir una zona enorme en la memoria en cada desplazamiento del cursor. Obviamente, esto es ineficiente.
2. Pensando en un método para guardar imágenes y trabajar con ellas, me acordé de la función "ResourceReadImage()". Esta función lee el recurso y pone su máscara numérica en un array. Por lo tanto, - no hay necesidad de guardar la imagen, porque ya está guardada a nivel de terminal y puede ser llamada usando esta función. Esto simplifica enormemente la tarea. Y así: puedes obtener la imagen con "ResourceReadImage()", meterla en un array y luego cambiar los valores del array, relativos a un elemento concreto que esté "bajo el evento" de la interfaz. Este enfoque parece más atractivo, en mi opinión. Sin embargo, la pregunta sigue siendo: ¿cuánto tiempo se tarda en llenar el array con una imagen utilizando "ResourceReadImage()"? Evidentemente, esto también depende de la zona del kanvas. Puede que no se note en absoluto, pero en cualquier caso debería cargarse sólo una vez mientras el cursor esté situado en una zona concreta del kanvas. Al pasar a otro kanvas, puedes borrar la matriz y cargar la imagen del otro kanvas.
De todos modos, no tengo una solución definitiva ahora mismo. Tengo que probar con la función "ResourceReadImage()", medir el tiempo de carga de la imagen y desarrollar un sistema de trabajo con áreas de imagen en el array.
Eso es todo por ahora.Реter Konow:
En mi implementación de la interfaz, el número de lienzos (recursos, lienzos) puede ser varias veces mayor que el número de ventanas, lo cual es necesario por la práctica.
Su práctica lo requiere.
Pero, como muestra su propia práctica, esta aplicación es defectuosa en términos de velocidad y comodidad.
Como muestra la práctica, es más conveniente trabajar con un lienzo y no hay obstáculos para dibujar temporalmente la ventana de la mesa en su lienzo y luego usar BitBlt en el principal.
No sé por qué has planeado "debe haber muchas matrices". "Pero tú mismo ves que es un camino sin salida.
Esto es lo que requiere su práctica.
Pero, como muestra su propia práctica, esa aplicación es defectuosa en términos de rapidez y comodidad.
Como muestra la práctica, es más conveniente trabajar con un lienzo y no hay obstáculos para dibujar temporalmente la ventana de la mesa en su lienzo y luego usar BitBlt en el principal.
No sé por qué has planeado "debe haber muchas matrices, además - indefinidamente muchas... "Pero tú mismo ves que es un camino sin salida.
Tal vez haya encontrado una solución mejor. Me encantaría verlo. Si puedes, cuelga un gif donde se vea claramente la velocidad de respuesta de los elementos al hacer clic. Después publicaré mi gif. Tú verás de qué hablo y yo veré de qué hablas.
No he grabado el vídeo, pero te envío un ejemplo, es un boceto rápido.
Hay 600 listas desplegables.
Mueve el ratón - con cada evento y cambio de color el CCanvas general se redibuja. consigues esa interactividad.
Puedes ver el tamaño final en las propiedades del mapa de bits - 1500x600 px (comparado con tus 800x500 y 250ms de retraso). Lo que equivale a 900.000 píxeles, y todos se redibujan al instante. No hay segundos de por medio.
Cada lista se representa primero en su propio lienzo en su propio tamaño (para que no se desborde) y luego se introduce en el conjunto. Así que tenemos 600 llamadas a ResourceCreate por evento de ratón.
Esto significa, como se puede ver por la velocidad de reacción, que los fotogramas son suficientes para mostrar los dibujos animados.
Los desarrolladores de MT dieron una herramienta satisfactoria sin retrasos (me refiero a ResourceCreate bitmaps)
No he grabado el vídeo, pero te envío un ejemplo.
hay 600 listas desplegables.
Mueve el ratón - con cada evento y cambio de color el CCanvas general se redibuja.
Puedes ver el tamaño final en las propiedades del mapa de bits - 1500x600 px (comparado con tus 800x500 y 250ms de retraso). Lo que equivale a 900.000 píxeles, y todos se redibujan al instante. No hay segundos de por medio.
Cada lista se representa primero en su propio lienzo en su propio tamaño (para que no se desborde) y luego se introduce en el conjunto. Así que tenemos 600 llamadas a ResourceCreate por evento de ratón.
Esto significa, como se puede ver por la velocidad de reacción, que los fotogramas son suficientes para mostrar los dibujos animados.
Los desarrolladores de MT dieron una herramienta satisfactoria sin retrasos (me refiero a ResourceCreate bitmaps)
Bueno, eso es suficiente para confirmar tus palabras... Sin embargo, repito mi pregunta de ayer: ¿se guarda la imagen?
Dije ayer - si almacena la imagen una vez creada, cambia sólo un área específica en ella, y envía a ResourceCreate() inmediatamente, no habrá ningún retraso. Su método de trabajo con el lienzo aún no me resulta familiar. Todavía no sé cómo ha conseguido este resultado.
Tengo otra pregunta: utilizando la clase CCanvas para crear el ejemplo anterior, ¿podría describir el principio de implementación de esta solución?
Tal vez se utilicen allí operaciones de tipo bitwise para procesar la imagen. Todavía no he tratado con ellos.
P.D. Sin embargo, me gusta resolver los secretos yo mismo...) De todos modos, resolveré este problema.
utilizando la clase CCanvas para crear el ejemplo anterior, ¿puede describir el principio de implementación de esta solución?
el principio es lineal - recorre la lista de controles y dibuja cada uno en la posición requerida en el lienzo.
Para dibujar los controles sólo se utilizan las funciones de CCanvas. No he dibujado nada propio.
por ejemplo, las listas en forma colapsada se dibujan como dos elementos - en este ejemplo, botones (esto es diferente en otros estilos)
las funciones del lienzo se llaman
FillRectangle // rellenar el fondo
Rectángulo // marco alrededor
FontSet // establecer la fuente
TextOut // texto de salida
Es posible que allí se utilicen operaciones a nivel de bits para procesar la imagen.
no.
¿se guarda la imagen?
sí, en el array que está en CCanvas
si almacena una imagen una vez creada, cambia sólo un área específica en ella, y la envía inmediatamente a ResourceCreate(), no habrá ningún retraso.
no es del todo correcto.
En mi ejemplo se redibuja todo el array. El array se borra y todo el lienzo se rellena de nuevo en cada redibujado. Luego se llama a ResourceCreate.
En mi ejemplo, se redibuja todo el array. El array se borra y todo el lienzo se rellena de nuevo en cada redibujado. Luego se llama a ResourceCreate.
Gracias por la elaborada respuesta.
Extrañamente, a mí me pasa lo mismo. La imagen de toda la ventana se recrea completamente en cada evento de la interfaz. Se construye en una matriz local unidimensional, que se envía a ResourceCreate después de que este procedimiento se complete.
No sé por qué me retrasa... Mañana publicaré un gif en el que mostraré la correlación entre el tamaño de la ventana y la velocidad de respuesta de los elementos.
Todo esto es muy extraño...
Gracias por la respuesta detallada.
Extrañamente, a mí me pasa lo mismo. La imagen de toda la ventana se recrea completamente en cada evento de la interfaz. Se construye en una matriz local unidimensional, que se envía a ResourceCreate después de que este procedimiento se complete.
No sé por qué me retrasa... Mañana publicaré un gif donde mostraré la dependencia entre el tamaño de la ventana y la velocidad de respuesta de los elementos.
Todo esto es muy extraño...
Si no es difícil, haz una animación gif con la carga de la CPU en el administrador de tareas. O es más fácil publicar el archivo compilado, como lo hizoSergeev. Así que uno puede probarlo por sí mismo.
Bien, haré un vídeo de la carga de la CPU. Pero sobre el archivo compilado - no lo publicaré todavía.
Sólo muy avergonzado de los bichos...))
Cuando los arregle, prometo publicarlos.
Bien, haré un vídeo de la carga de la CPU. Pero sobre el archivo compilado - no lo publicaré todavía.
Sólo muy avergonzado de los bichos...))
Cuando los arregle, prometo publicarlos.