Galería de interfaces de usuario escritas en MQL - página 56

 
Andrey Barinov #:

Simplemente NO estoy usando el lienzo de stock :).

Y me pareció más fácil de implementar una interfaz multi-ventana en un mapa de bits. ¡Pero cada uno a lo suyo!

Por desgracia, no en todos los casos. Para mis tareas es técnicamente más fácil trabajar con un conjunto limitado de mapas de bits. Y 100% más rápido. Mucho más rápido.

Pero, para otros desarrollos otras soluciones funcionan mejor, así que sí - a cada uno lo suyo. :)

 
Nikolai Semko #:
No Perth, sigue siendo demasiado. Tu interfaz con todo el texto, sombras, etc. alcanza un máximo de 50ms en un procesador débil.
Busca el bug.
Haz un perfil. Mira qué funciones consumen el 95% del tiempo.
Puede que estés usando funciones ChartGet o XY (aunque no tengas un enlace a un gráfico).
De todos modos, ejecute el perfil. Sólo te llevará 40 segundos.

Sí, lo comprobaré todo de nuevo. Pero ese no es el punto. El bloque de dibujo no sólo dibuja. Hay laberintos lógicos dentro de él que procesan los eventos entrantes. Son necesarios para determinar qué dibujar y qué no. Elige de dónde tomar las imágenes, dónde y cómo superponerlas. Si fuera una simple función de dibujo de 100 líneas, no habría nada que decir. Pero se trata de un mecanismo masivo para garantizar que se dibuja TODO.

Merece la pena tenerlo en cuenta)).

 
Andrey Barinov #:

Simplemente NO estoy usando el lienzo de stock :).

...

Y esto, es una agradable sorpresa. :) El autodesarrollo siempre mola. Aunque sea imperfecto.

No me molesta la clase Ccanvas (incluso incluí su funcionalidad en los archivos constructores), pero todavía no la uso. La palabra clave es "todavía". Tengo grandes planes para ella. En el futuro.

 
Comprobaré la velocidad de renderizado de un lienzo verde en blanco del tamaño del gráfico y lo publicaré aquí.
 
Реter Konow #:

Sí, lo comprobaré todo dos veces. Pero esa no es la cuestión. El bloque de dibujo no sólo dibuja. Hay laberintos lógicos en su interior que procesan los eventos entrantes. Son necesarios para determinar qué dibujar y qué no. Elige de dónde tomar las imágenes, dónde y cómo superponerlas. Si fuera una simple función de dibujo de 100 líneas, no habría nada que decir. Pero se trata de un mecanismo masivo para garantizar que se dibuje TODO.

Merece la pena tenerlo en cuenta)).

No, cuando se implementa correctamente, el modelo de eventos no tarda más de un microsegundo (una millonésima de segundo), aunque haya miles de comprobaciones.
Busca un error.
Y deja de ponerte a la defensiva. Nadie te está atacando, sólo quieren ayudarte.
Yo tengo lags notables (>300 ms) a partir de 100 mil objetos, y ligados al precio-tiempo.
 
Nikolai Semko #:
No, cuando se implementa correctamente, el modelo de eventos no tarda más de un microsegundo (una millonésima de segundo), aunque haya miles de comprobaciones.
Busca un error.
Y deja de ponerte a la defensiva. Nadie te está atacando, sólo quieren ayudarte.
Tengo lags notables (>300 ms) a partir de 100 mil objetos, y ligados al precio-tiempo.

No estoy a la defensiva))) Ja ja. Sólo explicando. ))

Ok. Empezaré con una prueba sencilla. Llenaré un lienzo a pantalla completa con un color y mediré el tiempo. Tú haz mediciones de tu función de renderizado y entonces quedará más claro si tengo frenos en mi código. Puede que los haya. No lo discuto. Necesito comprobarlo.

 
Реter Konow #:

No estoy a la defensiva). Ja, ja. Sólo me explico. ))

Bueno. Empezaré con una prueba sencilla. Llenaré un lienzo a pantalla completa con un color y mediré el tiempo. Tú haz mediciones de tu función de renderizado y entonces quedará más claro si tengo frenos en mi código. Puede que los haya. No lo discuto. Necesito comprobarlo.

Pensé que tal vez usted nunca ha trabajado con perfiles. Tampoco trabajas con depuración.


 
Nikolai Semko #:

Pensé que tal vez nunca has trabajado con perfiles. Tampoco trabajas con depuración.


No con depuración. No puedo hacerlo por el código ruso. He trabajado con profiling. Pero hace mucho tiempo. Me gusta codificar a la antigua. Es lo que hay.

Lo haré mañana. Los últimos días, he estado trabajando de 6:00 a.m. a 10:00 a 11:00 p.m.. De vez en cuando. Estoy un poco cansado.
 
Probablemente la velocidad pueda dejarse en un segundo plano y optimizarla no es algo que pueda hacerse rápidamente, por ahora es mejor mejorar la funcionalidad.
 
hini #:
Probablemente la velocidad pueda relegarse a un segundo plano, y optimizarla no es algo que pueda hacerse rápidamente, por ahora es mejor mejorar la funcionalidad.
Bueno, siempre es bueno para un programador mejorar la velocidad. Y en general, estoy de acuerdo. Es razonable. Es muy importante establecer prioridades en el desarrollo. Especialmente en proyectos tan grandes. Para mí era importante saber hasta qué punto la velocidad es importante para los usuarios. Por así decirlo, para obtener feedback. La velocidad por sí sola no formaba parte de mis planes iniciales. Sólo quería que los usuarios no se encogieran de miedo al ver la interfaz. :)

Por supuesto, la funcionalidad de los elementos sigue siendo mi prioridad. Motor, elementos, bugs. Eso es lo principal.