Realización de un proyecto crowdsourced en Canvas - página 32
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
Así es exactamente como lo construí. Básicamente, tomé la biblioteca estándar como base, porque tiene muy bien trabajados los momentos de transferencia de eventos y algunas otras cosas. Anatoly crea agrupaciones para cada clase de elementos, en la estándar todo se reduce a un objeto base.
...
En sus ejemplos Nikolay muestra que no es necesario molestarse en almacenar todos los datos de las áreas locales porque el repintado de todo el lienzo es tan rápido, que no es necesario bajar a los detalles y basta con redibujar todo el lienzo de una vez.No es tan sencillo. Imagínese que ha dibujado una tabla grande (todo el gráfico), donde una de las celdas cambia de valor 20 veces por segundo. Si se redibuja todo el lienzo, la carga del procesador aumentará hasta un 40% o más. Una forma absolutamente errónea de trabajar con un lienzo. Es necesario redibujar los elementos por separado, de lo contrario las tablas, los cristales y las diferentes animaciones locales sobrecargarán el procesador y ralentizarán la ejecución de otras funciones (si están en un hilo común).
Los experimentos de Nikolay hasta ahora demuestran lo contrario. Redibuja todo el contenido del lienzo de una sola vez, y es claramente visible en el código.
Pero sigo estando a favor de los cambios locales. Pero este enfoque tiene sus propias dificultades, que aún no he resuelto.
Los experimentos de Nikolay hasta ahora demuestran lo contrario. Redibuja todo el contenido del lienzo de una sola vez, y es claramente visible en el código.
Pero sigo estando a favor de los cambios locales. Pero este enfoque tiene sus propias dificultades que aún no he resuelto.
Considero a Nikolay mi amigo y ha alcanzado grandes cotas en el trabajo con lienzos, pero todavía no ha realizado experimentos completos con controles. Sobre todo con las mesas y los cristales. En cualquier caso, no tengo conocimiento de ninguno.
La conclusión es la siguiente: Un lienzo es una matriz de datos. Los datos se modifican y se vuelven a guardar en los eventos de cambio. Si la matriz incluye todos los píxeles del espacio del gráfico - entonces su tamaño = altura*ancho del gráfico. Si hay un cambio local de los valores de los píxeles dentro de la matriz, no hay necesidad de hacer un bucle completo en toda la matriz y restablecer todos los valores. Hay que hacer un bucle en la zona modificada, establecer los valores y salir del bucle. De lo contrario, sea como sea, es una pérdida de recursos y de tiempo.
Y hay muchas dificultades con este enfoque. La principal es crear objetos propios totalmente funcionales, encontrarlos y procesarlos en el propio lienzo. El CCanvas interno no es adecuado para eso. No "vería" tus elementos y no puedes acceder a ellos a través de él. No tiene esa funcionalidad.
Considero a Nikolai un amigo mío, y ha alcanzado grandes cotas con el lienzo, pero todavía no ha hecho experimentos en toda regla con los mandos. Sobre todo con mesas y un vaso. En cualquier caso, no tengo conocimiento de ninguno.
La conclusión es la siguiente: Un lienzo es una matriz de datos. Los datos se modifican y se vuelven a guardar en los eventos de cambio. Si la matriz incluye todos los píxeles del espacio del gráfico - entonces su tamaño = altura*ancho del gráfico. Si hay un cambio local de los valores de los píxeles dentro de la matriz, no hay necesidad de hacer un bucle completo en toda la matriz y restablecer todos los valores. Hay que hacer un bucle en la zona modificada, establecer los valores y salir del bucle. De lo contrario, sea como sea, es una pérdida de recursos y de tiempo.
Y hay muchas dificultades con este enfoque. La principal es crear objetos propios totalmente funcionales, encontrarlos y procesarlos en el propio lienzo. El CCanvas interno no es adecuado para eso. No "vería" tus elementos y no puedes acceder a ellos a través de él. Esta funcionalidad no existe.
Entiendo todo esto muy bien y soy muy consciente de ello. He creado mis propias clases de objetos y todo funciona bien.
Entiendo todo esto muy bien y soy muy consciente de ello. Tengo mis clases de objetos creadas y todo funciona bien.
En este caso, puede comprobarlo creando una tabla y actualizándola de dos maneras: localmente (cada celda por separado) y de una vez toda la tabla.
Las animaciones de Nikolai tienen en su mayoría una baja tasa de refresco, y por lo tanto, redibujar simultáneamente todo el lienzo no resulta una superposición. Pero si se aumenta la frecuencia de refresco a 5 veces por segundo, se observa un aumento del consumo de recursos de la CPU. Si hay que redibujar toda la animación - no hay salida, pero si es una sola y pequeña zona interior - mejor sólo esa.
La propia frecuencia -5 veces por segundo- puede darse en una tabla en la que los valores cambian de forma asíncrona. Esta situación me ocurrió en MT4, cuando conecté la tabla al probador a través de recursos. Allí, a la velocidad 31, todos los parámetros cambian tan rápido que un redibujado incorrecto de la tabla provocaba una carga de la CPU del 50% o más. Ni siquiera el rediseño local de los elementos lo salvó por completo. Se me ocurrió la idea de reducir la velocidad de visualización de los valores. Los propios valores cambiaban a un ritmo natural, pero se emitían a las celdas con una frecuencia menor. Esto resolvió el problema.
He aquí un ejemplo. 1000 celdas deben cambiar de valor a una velocidad de 25ms. En realidad, las celdas cambian de valor aproximadamente una vez cada 500ms y la carga de la CPU es de un 50%. (Esto es MT4 y la tabla está dibujada).
https://www.mql5.com/ru/forum/293630/page160
Aquí hay un ejemplo con el probador. La tabla se dibuja, pero no salva al procesador de la sobrecarga. :) (velocidad del probador 31, actualización de la célula completa (sin salto de pines)).
https://www.mql5.com/ru/forum/293630/page148
No es tan sencillo. Imagine que tiene una tabla grande (para todo el gráfico) en la que una de las celdas cambia de valor 20 veces por segundo. Si se redibuja todo el lienzo, la carga del procesador aumentará hasta un 40% o más. Una forma absolutamente errónea de trabajar con el lienzo. Es necesario redibujar los elementos por separado, de lo contrario las tablas, los cristales y las diferentes animaciones locales sobrecargarán el procesador y ralentizarán la ejecución de otras funciones (si están en un hilo común).
No sé muy bien de dónde sacas las cifras. Mira el ejemplo perfectamente simple de Nikolai https://www.mql5.com/ru/forum/227736/page44#comment_13445909. En un kanvas del tamaño de un gráfico, se generan varios objetos que se pueden arrastrar y soltar en el gráfico (en el kanvas). Se redibuja todo el lienzo. No hay ninguna ralentización.
No sé muy bien de dónde sacas las cifras. Mira el ejemplo perfectamente simple de Nikolai https://www.mql5.com/ru/forum/227736/page44#comment_13445909. En un kanvas del tamaño de un gráfico, se generan varios objetos que se pueden arrastrar y soltar en el gráfico (en el kanvas). Se redibuja todo el lienzo. No hay ninguna ralentización.
Fíjate en los ejemplos anteriores.
Inserta los enlaces a las hifas.Este es un ejemplo de cómo ralentizar la salida de valores a las celdas y reducir la carga del procesador:
https://www.mql5.com/ru/forum/293630/page148
No sé muy bien de dónde sacas las cifras. Mira el ejemplo perfectamente simple de Nikolai https://www.mql5.com/ru/forum/227736/page44#comment_13445909. En un kanvas del tamaño de un gráfico, se generan varios objetos que se pueden arrastrar y soltar en el gráfico (en el kanvas). Se redibuja todo el lienzo. No hay ninguna ralentización.
La tasa de refresco en ese ejemplo es normal. Por lo tanto, no hay ralentización.