Lienzo vs. Etiquetas - página 7

Nuevo comentario
 
Mihail Matkovskij:

¿Hay alguna información donde se pueda leer más sobre esto en alguna parte? Aunque lo tengo bastante claro, ¡no deja de ser un tema interesante! Ahora queda hacer la variante de control de actualización del mapa de bits y probarla. Me sorprenderá que el mapa de bits resulte más rápido que las etiquetas.

Admito que con pocas etiquetas, su uso tiene ventaja de velocidad sobre los kanvas, porque BitMap se rellena en C++, no en MQL5. Sin embargo, es poco probable, la formación del texto debe ser la misma en el lienzo también, porque la formación del texto BitMap se realiza por win-funciones en ambos casos. Creo que en el caso de Label estos objetos están enriquecidos con propiedades de eventos (se pueden arrastrar y soltar con el ratón) y eso hace que su construcción sea más pesada al final.

 

Sobre la velocidad de Canvas, hay una pregunta.


La tarjeta de vídeo está integrada en la CPU.


Ejecutando un código como este.

#include <fxsaber\Usage\Usage.mqh> // https://www.mql5.com/ru/code/33875

void OnInit()
{  
  USAGE::MinInterval = 100 * 1000; // 100 ms.
  
  EventSetMillisecondTimer((int)USAGE::MinInterval / 1000);  
}

void OnTimer()
{
  _USAGE // Расчет нагрузки.

  USAGE::GraphCreate(1200, 900, 200); // Вывели график нагрузки.
}

void OnDeinit( const int )
{
  USAGE::GraphDelete(); // Удалили график нагрузки.
}

En resumen, mide el tiempo de ejecución de OnTimer cada 100 ms. Además, traza un gráfico de mediciones dentro de OnTimer. Esto es lo que se consigue.

Se come el 15-20%. Aparentemente, es una tarjeta gráfica lenta. Pero la cuestión es diferente. Si empiezo a mover un gráfico de precios con el ratón (manteniendo pulsado el botón izquierdo del ratón y moviéndolo de izquierda a derecha), la carga se multiplica por dos. Es claramente visible en la animación de arriba. ¿A qué se debe esta peculiaridad?


Una vez más. OnTimer tarda el doble si se mueve el gráfico de precios con el ratón.

 
fxsaber:

Sobre la velocidad de Canvas, hay una pregunta.


La tarjeta de vídeo está integrada en la CPU.


Ejecutando un código como este.

Brevemente, mide el tiempo de ejecución de OnTimer cada 100 ms. Además, traza un gráfico de mediciones dentro de OnTimer. Esto es lo que se consigue.

Se come el 15-20%. Aparentemente, es una tarjeta gráfica lenta. Pero la cuestión es diferente. Si empiezo a mover un gráfico de precios con el ratón (al mantener pulsado el botón izquierdo del ratón moviéndose de izquierda a derecha), la carga se multiplica por dos. Es claramente visible en la animación de arriba. ¿A qué se debe esta peculiaridad?


Una vez más. El OnTimer tarda el doble si se mueve el gráfico de precios con el ratón.

Lo más probable es que sus librerías tengan el control CHARTEVENT_CHART_CHANGE, para poder cambiar el tamaño del lienzo en caso de necesidad (si el tamaño del gráfico ha cambiado), pero para averiguarlo hay que ejecutar la terriblemente lenta (hasta ahora) función asíncrona ChartGet...
Esto provoca lentitud.
Tendría más sentido para MQ separar el evento CHARTEVENT_CHART_CHANGE, y hacer un CHARTEVENT_CHART_SIZE_CHANGE separado, por ejemplo. Hay demasiadas cosas en el evento CHARTEVENT_CHART_CHANGE: la llegada de una nueva barra, el desplazamiento de las barras, el cambio de la escala vertical de precios, el cambio de tamaño de la ventana.

 
Nikolai Semko:
Es muy posible que con un pequeño número de Etiquetas su uso tenga ventajas de velocidad sobre Kanvas porque el BitMap se rellena en C++ y no en MQL5. Sin embargo, es poco probable, la formación del texto debe ser la misma en el lienzo también, porque la formación del texto BitMap se realiza por win-funciones en ambos casos. Creo que en el caso de Label estos objetos también están revestidos de propiedades basadas en eventos (se pueden arrastrar y soltar con el ratón) y eso hace que su construcción sea más pesada al final.

De hecho, las etiquetas pueden ser más rápidas. Depende de cuántos haya en el gráfico... Hice una comprobación de la actualización y, efectivamente, me sorprendieron los resultados. Límite tomado de la velocidad de fotogramas mínima agradable a la vista, 24 fps, si no me equivoco. Tengo unos 41 milisegundos. Poner un límite a Kanvas y, oh maravilla, me sorprendió. Es algo que vuela, comparado con la incesante actualización de las etiquetas. Pero cuando puse la misma restricción para la pantalla en las Etiquetas, fue incluso más rápido que la pantalla basada en Kanvas. Pero no me adelantaré, presentaré todos los resultados de las pruebas más adelante.

 
fxsaber:

Si empiezo a mover el gráfico de precios con el ratón (mover a la izquierda y a la derecha con el botón izquierdo del ratón pulsado), la carga se duplica. En la animación de arriba se ve perfectamente. ¿A qué se debe esta peculiaridad?

Con el modelo de eventos de Windows - incluso si se mueve el ratón rápidamente, la carga en la CPU comienza a aumentar, sin importar qué aplicación estaba en foco

ZS: comprobado con el administrador de tareas de Win10... No creo que Win10 haya cambiado el modelo de eventos de forma drástica, es más probable que el gestor de tareas funcione de forma diferente

 
Nikolai Semko:

Lo más probable es que sus librerías tengan el control CHARTEVENT_CHART_CHANGE para poder cambiar el tamaño del lienzo en caso de necesidad (si el tamaño del gráfico ha cambiado), pero para averiguarlo hay que realizar la función asíncrona ChartGet, terriblemente lenta (hasta ahora)...
Esto provoca un frenazo.
Tendría más sentido para MQ separar el evento CHARTEVENT_CHART_CHANGE, y hacer un CHARTEVENT_CHART_SIZE_CHANGE separado, por ejemplo. El evento CHARTEVENT_CHART_CHANGE tiene muchas cosas: llegada de una nueva barra, desplazamiento de las barras, cambio de la escala vertical de precios, cambio de tamaño de la ventana.

Nada de esto está en el código anterior.

 
Igor Makanu:

con el modelo de eventos de Windows - incluso si se mueve el ratón rápidamente, la carga de la CPU comienza a aumentar, sin importar qué aplicación estaba en foco

ZS: He comprobado con el administrador de tareas de Win10... No muestra ningún aumento en la carga de la CPU por alguna razón, en Win7 la carga aumentaba en el mismo PC si movía el ratón rápidamente - Dudo que Win10 haya cambiado fundamentalmente el modelo de eventos, lo más probable es que el administrador de tareas funcione de manera diferente

Gracias, no lo sabía. Me sorprende que el ratón sea capaz de ralentizar el programa MQL a la mitad.

ZS ¿Soy yo el único que ha obtenido este resultado?
fxsaber:

Se come el 15-20%. Al parecer, la tarjeta de vídeo es lenta.

 
fxsaber:

Gracias, no lo sabía. Me ha sorprendido que un ratón sea capaz de ralentizar un programa MQL a la mitad.

Entonces es legítimo tener retrasos con ticks y demás. La HFT con ese modelo de eventos es como un campo de minas.

 
fxsaber:

Nada de esto está en el código anterior.

Sí, no he visto que sea el gráfico interno.
Pues a juzgar por el perfil, el origen de los frenos al desplazar el gráfico está en esta línea:

Perfilado con desplazamiento activo:

Perfilado con movimiento activo del ratón sin desplazamiento (sin el LKM pulsado):

ZS: Así que la fuente de los frenos no son los kanvas, sino los objetos.

 
Mihail Matkovskij:

También podrías haberlo comprobado en el gráfico. Sin embargo, pensé que sería más fácil hacerlo en el probador.

Este es un enfoque erróneo. Sobre todo porque el probador visual tiene un modelo de renderizado diferido diferente, para no ralentizar completamente el proceso de pruebas.

Así que, como has dicho, se necesita más tiempo para dibujar el texto en las etiquetas que para dibujar OBJ_BITMAP_LABEL.

No lo he dicho.

Señalé los errores obvios y expliqué cómo funciona el sistema de renderización.

1234567891011121314...18
Nuevo comentario