Realización de un proyecto crowdsourced en Canvas - página 19

 

.

Aquí está el vídeo que prometí publicar. La calidad de la imagen es pobre, pero no impide ver los retrasos en la respuesta.

De hecho, hay menos retraso en la terminal. Cuando la grabadora está encendida, todo es el doble de lento. El procesador también carga mucho más.

Por lo tanto, no es posible obtener una idea completamente objetiva de la velocidad de reacción a partir de este vídeo, pero muestra claramente un patrón entre la frecuencia de actualización de la ventana y el tamaño de la misma.

(Por eso hice varias ventanas de diferentes tamaños).

Creo que tengo la razón exacta de la ralentización de la respuesta de la imagen. Es la llamada constante de la función ColorToARGB(). En cada evento y en cada píxel llamo a esta función. En lugar de calcular los colores una vez y usarlos ya, los recalculo todo el tiempo.

Creo que esta es la cuestión.

P.D. Se me olvidó añadir que el número total de objetos de todas las ventanas es de 35.

 
Реter Konow:

.

Aquí está el vídeo que prometí publicar. La calidad de la imagen es pobre, pero no impide ver los retrasos en la respuesta.

De hecho, hay menos retraso en la terminal. Cuando la grabadora está encendida, todo es el doble de lento. El procesador también carga mucho más.

Por lo tanto, no es posible hacerse una idea completamente objetiva de la velocidad de reacción a partir de este vídeo, pero puedo ver claramente un patrón entre la tasa de refresco y el tamaño de la ventana.

(Por eso hice varias ventanas de diferentes tamaños).

Creo que tengo la razón exacta de la ralentización de la respuesta de la imagen. Es la llamada constante de la función ColorToARGB(). En cada evento y en cada píxel llamo a esta función. En lugar de calcular los colores una vez y usarlos ya, los recalculo todo el tiempo.

Creo que esa es la cuestión.

P.D. Se me olvidó añadir que el número total de objetos de todas las ventanas es de 35.

¿Es posible consultar las fuentes? Para mí, para mí, para la experiencia .
 
Vladimir Pastushak:
¿Es posible echar un vistazo al código fuente? Para mí, para mi experiencia.
Sí, en esta página he puesto un bloque de funciones que dibujan todas estas ventanas juntas. https://www.mql5.com/ru/forum/92113/page16
Делаем краудсорсовый проект по Canvas
Делаем краудсорсовый проект по Canvas
  • www.mql5.com
Приветстсвую кодеров. Есть интересная задача сделать действительно что-то полезное, и думаю что краудсорс будет хорошим вариантом...
 
Se ha resuelto el problema de las reacciones retardadas. La solución era la siguiente:

Una imagen se crea una vez. Esta es la primera vez que se tarda más en dibujarla, porque la imagen consta de muchas partes, y dibujar cada parte es una llamada a las funciones de dibujo, cada una de las cuales hace un bucle sobre la parte e inicializa los valores en el array.

Te explicaré cuál era el problema:

Antes, al dibujar los detalles de una imagen, hacía un bucle sobre toda el área de la imagen y eso es lo que creaba el retraso. Para una ventana de 500×500 píxeles, he tenido que redibujar unas 300 partes en cada repintado, lo que ha supuesto (500×500×300×número de funciones de dibujo) interacciones en ciclos en cada repintado. Resulta que esto lleva tiempo incluso para un ordenador.
La solución fue la siguiente: en lugar de volver a dibujar la imagen en cada evento que requiera repintar un detalle particular dentro de la imagen, dibujo la imagen una vez, y en los siguientes repintados la devuelvo a un array usando ResourceReadImage().

Luego redibujo la parte sin hacer un bucle sobre toda la imagen, pero calculé la ubicación de los píxeles de la parte de la imagen en la matriz de la imagen mediante una fórmula especial y la redibujé solamente. De este modo, no se realiza una integración innecesaria. Además, he fusionado las funciones de dibujo en una sola, lo que también ha hecho más eficiente el mecanismo.





 
¿Es realista acelerar el renderizado en Canvas utilizando OpenCL?
 
Timur Gatin:
¿Es realista acelerar el renderizado en Canvas con OpenCL?


Sí. OCL tiene la capacidad de paralelizar el procesamiento + la capacidad de operar en vectores - esto acelera el proceso de renderizado/superposición.

Más información sobre el uso de vectores en el artículo de Mathemat https://www.mql5.com/ru/articles/407

OpenCL: от наивного кодирования - к более осмысленному
OpenCL: от наивного кодирования - к более осмысленному
  • 2012.06.05
  • Sceptic Philozoff
  • www.mql5.com
В данной статье продемонстрированы некоторые возможности оптимизации, открывающиеся при хотя бы поверхностном учете особенностей "железа", на котором исполняется кернел. Полученные цифры весьма далеки от предельных, но даже они показывают, что при том наборе возможностей, который имеется здесь и сейчас (OpenCL API в реализации разработчиков терминала не позволяет контролировать некоторые важные для оптимизации параметры - - в частности, размер локальной группы), выигрыш в производительности в сравнении с исполнением хостовой программы очень существенен.
 
Igor Volodin:


Sí. OCL tiene la posibilidad de paralelizar el procesamiento + la posibilidad de operar con vectores - esto acelera el proceso de dibujo/colocación.

Más información sobre el uso de vectores en el artículo de Mathemat https://www.mql5.com/ru/articles/407

¿Has comparado la velocidad de Erase() de CCanvas y el bucle PixelSet() realizado en OpenCl? En teoría, con un buen aumento de velocidad, se puede hacer un código de dibujo tonto sin almacenar en caché los resultados intermedios y otras complicaciones.

Por cierto, ¿se mezclan las capas con esta fórmula?


 

Sí, la fórmula está sacada de la wikipedia, para cada componente de color: Resultado = Fondo + (Primer plano - Fondo) * Alfa;

Por cierto, hay un problema con el borrado en la OCL. No existe un análogo de memset (a diferencia de CUDA). Por eso ahora tengo que hacer un Erase en el host y copiar el array limpiado a través de CLBufferWrite, lo que ciertamente no es más rápido que un simple Erase.
Por otro lado, probé a hacer un array de tareas para las unidades de trabajo escribiendo 1 punto en el array pero no recuerdo la velocidad - parecía ser más lento que el método anterior.

Y en OCL 1.2 hayclEnqueueFillBuffer() que hace eso => según la sintaxis MQL debería haber CLBufferFill()

Pero este wrapper no está implementado (ya que la versión 1.1 está portado).

 
Igor Volodin:

Sí, la fórmula está sacada de la wikipedia, para cada componente de color: Resultado = Fondo + (Primer plano - Fondo) * Alfa;

Por cierto, hay un problema con el borrado en la OCL. No existe un análogo de memset (a diferencia de CUDA). Por eso ahora tengo que hacer un Erase en el host y copiar el array limpiado a través de CLBufferWrite, lo que ciertamente no es más rápido que un simple Erase.
Por otro lado, probé a hacer un array de tareas para las unidades de trabajo escribiendo 1 punto en el array pero no recuerdo la velocidad - parecía ser más lento que el método anterior.

Y en OCL 1.2 hayclEnqueueFillBuffer() que hace eso => según la sintaxis MQL debería haber CLBufferFill()

Pero este wrapper no está implementado (ya que la versión 1.1 está portado).

En la wiki inglesa, la fórmula es más interesante, se pueden mezclar dos capas semitransparentes. Esto puede hacer que la interfaz sea semitransparente y que haya otras lindezas.
 
Timur Gatin:
En la víctima inglesa, la fórmula es más interesante, se pueden mezclar dos capas translúcidas. Es posible hacer una interfaz translúcida y otras cosas bonitas.

En mi caso no lo he necesitado, todo se mezcla correctamente. Todo lo que esté por debajo de la capa A puede considerarse el sustrato, incluso si la capa B está encima, a través de la cual brilla el propio sustrato.