Galería de interfaces de usuario escritas en MQL - página 53
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
Rether, ¿considerarías cambiar el catálogo al inglés en futuras versiones? Los archivos de código fuente que contienen los nombres de los catálogos se sustituyen por texto.
Por supuesto. Ya lo he pensado. Haré una versión especial con los nombres de los catálogos en inglés.
No estoy comprobando los archivos sólo los comentarios aquí. Pero ese 'lag' para mi no parece estar relacionado con la velocidad, sino con el uso de ChartRedraw antes de crear completamente el nuevo recurso. Porque se queda con el lienzo en blanco y luego muestra el nuevo lienzo.
Sí, claro. Lo he pensado. Haré un lanzamiento especial que incluya el nombre del catálogo en inglés.
Yo sugeriría no hacer una versión especial con catálogos en inglés, sino hacer sólo una de esas versiones en inglés, simplemente cambiando el nombre del catálogo a inglés, y el siguiente paso sería cambiar el nombre del archivo a inglés, y seguirás escribiendo el código fuente en ruso.
Estoy de acuerdo. Poco a poco cambiaré los nombres de los directorios al inglés. Así será más racional.
No he comprobado los archivos, sólo los comentarios aquí. Pero este "lag" para mí no parece estar relacionado con la velocidad, sino con el uso de ChartRedraw antes de que el nuevo recurso esté completamente creado. Porque muestra un lienzo en blanco y luego muestra el nuevo lienzo.
Interesante idea, intentaré probarla. Gracias.
Y entonces, una actualización...
Esta es una actualización provisional. En unos días lanzaré la siguiente versión. Habrá nuevas funcionalidades para la interacción del programa con los controles.
Tengo que decir esto: Trabajo en dos versiones - 2470 y la nueva. La mayor parte del desarrollo se realiza en la versión antigua. La compilación es más rápida: 4 segundos frente a 26-32 segundos. La nueva compilación funciona un poco diferente y se nota visualmente. A veces es más rápida, a veces más lenta. Tal vez sólo lo parezca. Es difícil encontrar una diferencia, pero a mí me parece que está ahí. La interfaz en la versión antigua vuela. En la nueva. casi vuela. Tal vez creo que es porque estoy acostumbrado.
Sin embargo, hay matices. Por ejemplo, hay un problema al cambiar de gráfico, cuando se devuelven valores incorrectos de altura y anchura del gráfico. Esto hace que la barra de tareas salte. Me las arreglé para evitar este problema, pero entonces la barra de tareas no reacciona a otros eventos de cambio de tamaño del gráfico. Al final - decidí dejarlo como estaba. La barra de tareas saltará al cambiar de gráfico (mientras haya un problema de devolución de valores incorrectos), pero se adaptará normalmente a otros eventos.
Pero eso no es todo. Resulta que los eventos de cambio de tamaño del gráfico no se producen instantáneamente y hay una pausa de medio segundo. Este retraso se superpone al tiempo de redibujar la barra de tareas y se obtiene un retraso decente. Aquí no puedo hacer nada.
Voy a decir esto: por supuesto, he acelerado significativamente los gráficos, pero todavía hay algunas otras soluciones no optimizadas en el código. Estoy trabajando duro en ellas. Principalmente se trata de la transición del foco de la ventana y la cola de redibujado. Ocurren algunas llamadas innecesarias. La barra de tareas se retrasa. Arreglé lo que tuve tiempo de arreglar, aunque no todo. Pero el resto es cuestión de los próximos días. Por lo demás, no hay mucho que mejorar... tal vez sólo peinar y perfumar el código para hacerlo fragante)).
En general, si depuramos todas las soluciones no optimizadas que quedan... volará... bueno, dentro de las velocidades disponibles para un programa MQL, por supuesto.
Tome la liberación.
Y entonces, una actualización...
...
Permítanme ponerlo de esta manera: los gráficos, por supuesto, significativamente acelerado, pero todavía hay algunas otras soluciones no optimizadas en el código. Estoy trabajando duro en ellos. Principalmente se trata de la transición del foco de la ventana y la cola de redibujado. Algunas llamadas innecesarias ocurren. La barra de tareas se retrasa. Arreglé lo que tuve tiempo de arreglar, aunque no todo. Pero el resto es cuestión de los próximos días. Por lo demás, no hay mucho que mejorar... tal vez sólo peinar y perfumar el código para hacerlo fragante)).
En general, si depuramos todas las soluciones no optimizadas que quedan... volará... bueno, dentro de las velocidades disponibles para un programa MQL, por supuesto.
Tome la liberación.
Permítanme dejar claro: estamos hablando de velocidad aquí. Si se corrigen los defectos de redibujado de la ventana en el evento de cambio de foco, la velocidad de la interfaz estará en el límite superior de un programa MQL. Los retrasos de la barra de tareas se pueden arreglar parcialmente. Se me ocurrió una buena solución - aplicar en la mecánica de la barra de tareas el principio de una ventana dinámica - no se ralentiza al cambiar de tamaño, cuando se tira por el marco. Se ajustará más rápida e imperceptiblemente. Y, por supuesto, tenemos que cancelar redibujos innecesarios. Esto es obligatorio. Pero si los propios eventos CHARTEVENT_CHART_CHANGE llegan al programa con retraso, el retardo visible de las reacciones de la barra de tareas es inevitable, aunque no tenga nada que ver.
Por lo demás, hay muchas direcciones de desarrollo y mejora de la interfaz.
Unas palabras más sobre la velocidad de la interfaz.
He pasado mucho tiempo comprobando retrasos y buscando frenos de renderizado. El bloque responsable de la disposición del kanvas está construido de tal manera que antes de inicializar el array que va a crear un recurso en la función ResourceCreate(), define los límites del bucle en los detalles de la ventana. Lo hace con la ayuda de filtros-condición configurados para comprobar los eventos entrantes. Cada evento que llama al bloque recibe límites de dibujo. Por ejemplo, en el evento de la reacción del elemento al pasar el cursor, se activa el filtro con los límites del bucle sólo en los detalles de un elemento en particular. El bloque selecciona sólo sus detalles en la imagen tomada. Y durante el ciclo sobre los detalles, dibuja selectivamente sólo ellos entre el resto de la imagen. Encuentra con precisión los lugares para inicializar y dibujar el detalle correcto del elemento correcto. Al mismo tiempo, omite correctamente el resto del espacio de la imagen.
Pero la aceleración no es sólo eso. El bloque no inicializa los puntos del lienzo si su color coincide con el valor requerido. Además, no "recorre" la matriz, sino que "salta", salvando las distancias. Esto reduce los ciclos en cientos de miles de iteraciones.
Y no sólo eso. Como el array de imágenes es global (declarado a nivel global), siempre almacena en su memoria el cambio de la última imagen. Y si se siguen produciendo cambios en el mismo lienzo, en lugar de borrar su matriz cada vez, se utiliza la imagen almacenada. Si el nombre del recurso no cambia en el siguiente evento, entonces no hay necesidad de llamar a ResourceReadImage(), y no hay necesidad de enviar el array del lienzo de nuevo para ser llenado. El bloque continúa trabajando con los datos restantes sin llamar a ResourceReadImage(), y actualiza la imagen con ResourceCreate() después del cambio.
Esto ahorra mucho tiempo en las llamadas a ResourceReadImage( ). Y también en limpiar y llenar el array. Es un buen uso de la memoria global, ¿no?
Cuando se redibujan ventanas, el bloque no se llama en absoluto. Los componentes de la ventana se borran y se crean y se les adjuntan los recursos previamente guardados. No hay renderizado.
Con todo esto, sigue habiendo lags, y son inevitables. Permítanme explicar lo que está pasando.
En la primera apertura de una ventana, o en la primera apertura de una pestaña, o en el evento de una lista de árbol, o al minimizar/desmodelar grandes espacios, hay un redibujado completo obligatorio de los lienzos. Hasta el momento de crear recursos de imagen que puedan ser enlazados/cambiados eficientemente muchas veces después, SIEMPRE hay que dibujar una imagen completa desde cero. El primer dibujo es SIEMPRE el más largo. No hay nada que guardar, no hay ninguna imagen guardada. Es al abrirlo por primera vez cuando siempre se notan los lags. Es inevitable.
Sin embargo, aquí también hay una buena solución: trasladar los lags de la apertura de ventanas al evento de carga. Lo que quiero decir: en la etapa de carga del constructor en el fondo dibujar todas las imágenes y guardarlas en los recursos de antemano, de modo que todo estaría listo al abrir. Entonces el usuario no verá ningún retraso al abrir las ventanas por primera vez. Esto es genial, por supuesto, pero hay un inconveniente. El retardo de la primera apertura se convertirá en un retardo de carga y su tiempo aumentará. Es difícil decir cuánto. Creo que, de media, en un segundo. Depende de la interfaz concreta.
Creo que esta opción es preferible. Prefiero dejar que el diseñador/interfaz de usuario cargue un poco más, pero no habrá más lags visuales de apertura.
Me interesa conocer vuestras opiniones al respecto.
Añadido:
Había una idea para guardar los recursos de la interfaz después de la primera carga a un archivo. Entonces las cargas posteriores serán mucho más rápidas, porque los recursos necesarios ya están a disposición del diseñador/motor. Hay que pensarlo.