Mi enfoque. El núcleo es el motor. - página 125
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í que se redibujan exactamente como has dicho.
Y la carga del procesador proviene de la animación:
Hay una reinicialización constante de los valores de la matriz de píxeles. Cada 16 milisegundos. Esto carga el procesador hasta un 40%.
Estaba tratando de averiguar cuál es exactamente la carga. Pensé que era guardar un recurso o leerlo. Resultó que era la reinicialización del array en el bucle de dibujo.
También resultó que una llamada constante de ObjectSetInteger(0, "MT object",OBJPROP_SELECTED,1); (cada 16 ms) también carga el procesador. En un 10% aproximadamente.
Utilizo esta llamada para decirle a otro EA que lea el recurso con los datos de la animación.
En total, obtiene +~50% de carga de la CPU durante la animación.
Lo siento, no me di cuenta de que ya no se trata de la lista de operaciones abiertas. Se han ido, creo, 2-3 páginas del hilo.
No, está bien. Acabo de subir la carga de la CPU porque voy a rehacer la comunicación entre el EA y el motor, lo que significa que la tabla de operaciones abiertas también tomará los datos de forma diferente.
Por qué hacer el periris 64 cuadros por segundo (16 ms), para el ojo es suficiente 32 cuadros por segundo.
Buena pregunta. De hecho, el temporizador no funciona bien. Hay saltos. 16,32,16,16...
Si usas 32, los saltos son de 64 ms. Y esto se nota. Además, hay otras cosas que también lastran y ralentizan el dibujo. Por ejemplo, la cola de eventos OnChartEvent().
Creo que afecta a la calidad de la animación. He intentado utilizar 25 ms. Luego el 16, y llegué a la conclusión de que el 16 transmite mejor un movimiento suave.
Más tarde skolnuyu motor con la animación 16 ms y 32 ms y verás por ti mismo. Aunque, tal vez sea ok....
Buena pregunta. De hecho, el temporizador no funciona bien. Hay saltos. 16,32,16,16...
Si usas 32, los saltos son de 64 ms. Y esto se nota. Además, hay otras cosas que también lastran y ralentizan el dibujo. Por ejemplo, la cola de eventos OnChartEvent().
Creo que afecta a la calidad de la animación. He intentado utilizar 25 ms. Luego el 16, y llegué a la conclusión de que el 16 transmite mejor un movimiento suave.
Más tarde skolnuyu motor con la animación 16 ms y 32 ms y verás por ti mismo. Aunque, tal vez sea ok....
Es que realmente no son 16ms, sino 1000/64=15,625ms. Por eso es mejor poner 30 ms en lugar de 32 ms, entonces habrá menos saltos. Es decir, si pones una pausa entre fotogramas de 33 ms, entonces la pausa real será de 15,625×3=46,875 ms.
¿Por qué? Simple, interesante.
¿Por qué? Simple, me pregunto.
Es que realmente no son 16ms, sino 1000/64=15,625ms. Por eso es mejor poner 30 ms en lugar de 32 ms, entonces habrá menos saltos. Es decir, si pones una pausa entre fotogramas de 33 ms, entonces la pausa real será de 15,625×3=46,875 ms.
De acuerdo, lo tendré en cuenta.
Si se reduce la frecuencia del temporizador, sin duda se reducirá la carga del procesador. Si no degrada la calidad de la animación, estupendo. La carga de la CPU puede reducirse hasta un 30 por ciento, pero seguirá siendo así.
Tendrás que soportarlo.
Es cierto que si el dibujo se distribuye entre diferentes hilos, (por ejemplo, parte de la animación dibuja el Asesor Experto, y parte el motor), entonces la carga sería casi eliminada. Tenemos que pensar...
Por desgracia, mi suposición no se confirmó.
Ahora he hecho un experimento: he puesto un EA en dos gráficos. El Asesor Experto carga el procesador en un 50%.
He descubierto que incluso cuando se trabaja con diferentes gráficos, la carga de la CPU se suma y la carga total de la CPU en el lado de MT es más del 90%.
Por lo tanto, incluso la división de los gráficos entre diferentes Asesores Expertos no ayudará. ¡La carga se va acumulando!
Por desgracia, mi suposición no se confirmó.
Ahora he hecho un experimento: he puesto un EA en dos gráficos. El Asesor Experto carga el procesador en un 50%.
He descubierto que incluso cuando se trabaja con diferentes gráficos, la carga de la CPU se suma y la carga total de la CPU en el lado de MT es más del 90%.
Por lo tanto, incluso la división de los gráficos entre diferentes Asesores Expertos no ayudará. ¡La carga se va acumulando!