Errores, fallos, preguntas - página 976
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
...
Es extraño, yo tengo la imagen contraria:
Tengo este resultado:
Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias
Errores, fallos, preguntas
Renat, 2013.04.27 13:32
Yo también haré las pruebas y escribiré los resultados.He olvidado por completo que cuando se prueban las etiquetas, el dibujo se deriva completamente del sistema MQL5 y se dibuja en el flujo de la interfaz. En MQL5, sólo se modifican las descripciones de las etiquetas.
Cuando se dibuja un mapa de bits, todo el dibujo se realiza dentro de MQL5 y sólo queda un único BitBlt muy rápido en el flujo de la interfaz.
Es decir, la prueba es completamente incorrecta porque el mapeo de marcadores no se prueba en absoluto. El refresco del gráfico es un comando asíncrono que sólo envía una notificación al hilo de la interfaz para que lo renderice. Como puede ver en la captura de pantalla con los costes de ChartRedraw.
Es mejor no usar Argb_normalize, ya que da un coste extra para la normalización del color. Es mejor pintar las cosas sencillas con colores puros.
El canal alfa tiene un atractivo estético. Cuando el texto se muestra de forma "transparente" encima de los gráficos/bolas, laconclusión obvia que hay que sacar es que hay una división de usos.
Si sólo quieres mostrar un mensaje/estadística, la etiqueta de texto es más rápida. Enel caso de crear controles (como botones) - mapa de bits, y sin opciones. Entonces puedes rellenar toda el área rectangular con color sólido, sin canal alfa/transparencia, sin demasiada frustración.
La eliminación de la función ChartRedraw() del bucle es incorrecta, porque la "operación atómica" del cambio de la propiedad de la etiqueta de texto no es manejada por el motor de vídeo del terminal.
Sí, exactamente de la misma manera que el trabajo con la matriz no es manejado por el motor de vídeo.
el problema es averiguar qué funciona más rápido: cambiar un mapa de bits o cambiar una etiqueta.
creación de mapas de bits pierde - eso es seguro.
y la representación de la carta en ambos casos es discutible y secundaria.
Piensa en los resultados. Puedes ver que 4 segundos por ciclo de cambio de etiquetas ???? es un sinsentido.
los cambios de las etiquetas deben ser comprobados puramente en el cambio, no interfiriendo con el subsistema de representación del gráfico.
de lo contrario, vería números comparables con un mapa de bits.
He olvidado por completo que cuando se prueban las etiquetas, el dibujo se deriva completamente del sistema MQL5 y se dibuja en el flujo de la interfaz. En MQL5, sólo se modifican las descripciones de las etiquetas.
Al dibujar un mapa de bits, todo el trabajo se realiza dentro de MQL5.
Pero la etiqueta sigue cambiando más rápido que el mapa de bits en términos de velocidad. Debido a la lentitud de las funciones GDI.
En otras palabras, las pruebas son completamente erróneas, ya que el mapeo de marcas no se prueba en absoluto. La actualización del gráfico es un comando asíncrono que sólo envía una notificación al hilo de la interfaz que se va a dibujar. Que es lo que se puede ver en la captura de pantalla con los costes de ChartRedraw.
Exactamente.
Creo que hay que hacer pruebas con algunas tareas pesadas específicas . ¿Quién se encargará de hacer una tarea de referencia como ésta?
- Dibujar un gráfico (por ejemplo, una onda sinusoidal) utilizando un montón de etiquetas (rectángulo) y utilizando un mapa de bits.
- dibujar una tabla de excel (rectángulo+etiqueta de texto) y como mapa de bits.
y otras opciones en las que los gráficos MT pueden ser sustituidos por mapas de bits.
comprobar los costes de los recursos para soportar un mapa de bits y un montón de objetos MT . + dependencia del tamaño de las zonas a rellenar.
Otra cosa que se puede ver en la prueba de etiquetas es que hay una operación de escritura unidireccional muy económica sin etiquetas de lectura. En este caso hay una piperización rápida máxima del flujo de comandos por escritura (utilizamos a propósito un sistema eficiente en este caso).
Pero si se mezcla la escritura con la lectura de datos de objetos, lo que suele ocurrir en el trabajo real, la velocidad disminuye drásticamente.
Actualización: También en el ejemplo de prueba de los marcadores hay un error crítico - sólo una modificación va a un marcador, no 26. Mira la fuente.
Es decir, la prueba es completamente incorrecta, ya que no comprueba la asignación de etiquetas en absoluto.
Los cambios en las etiquetas deben probarse únicamente para los cambios, sin que el subsistema de representación de gráficos sea barrido.
Yo, por supuesto, no estoy de acuerdo. Argumento: es deseable que el usuario vea el cambio de situación (estadísticas) con la mayor frecuencia posible, en cada tick. Por lo tanto, después de actualizar las estadísticas, deben mostrarse = ChartRedraw().
Esto es, por así decirlo, en términos de aplicación inmediata/carácter práctico del rendimiento.
En cuanto a los puntos de referencia esféricos en el vacío, esto es opcional.
pero la marca sigue cambiando más rápido que el mapa de bits en términos de velocidad. Debido a la lentitud de las funciones GDI.
También hay unerror críticoen el ejemplo de la prueba de la etiqueta : sólo se modifica una etiqueta, no 26. Mira la fuente.
El texto cambia en todas (la mitad) de las etiquetas, que están diseñadas para mostrar el valor del indicador, no su descripción. Cuando se ejecuta el script, se puede ver eso.
O no te entiendo. ¿De qué línea en particular estamos hablando?