Nikolai Semko : 실제로는 16ms가 아니라 1000/64=15.625ms입니다. 따라서 32ms가 아닌 30ms로 설정하는 것이 좋습니다. 그러면 간격이 줄어듭니다. 저것들. 프레임 사이의 일시 중지가 33ms로 설정된 경우 실제 일시 중지는 15.625×3=46.875ms가 됩니다.
그리고 MT에는 자체 내부 차트 업데이트 핸들러가 있으므로 ChartRedraw는 비동기식으로 작동하며 MT가 모든 것을 처리한다는 보장이 없다는 것을 잊어서는 안됩니다.
Nikolai Semko : 실제로 16ms가 아니라 1000/64=15.625ms입니다. 따라서 32ms가 아닌 30ms로 설정하는 것이 좋습니다. 그러면 간격이 줄어듭니다. 저것들. 프레임 사이의 일시 중지가 33ms로 설정된 경우 실제 일시 중지는 15.625×3=46.875ms가 됩니다.
그리고 MT에는 자체 내부 차트 업데이트 핸들러가 있으므로 ChartRedraw는 비동기식으로 작동하며 MT가 모든 것을 처리한다는 보장이 없다는 것을 잊어서는 안됩니다.
알겠습니다. 배우겠습니다.
물론 타이머의 주파수를 줄이면 프로세서의 부하가 줄어듭니다. 애니메이션 의 품질을 저하시키지 않는다면 훌륭합니다. 프로세서의 부하를 최대 30%까지 줄일 수 있지만 여전히 유지됩니다.
참아야 할 것입니다.
사실, 그림이 서로 다른 스레드 사이에 배포된다면(예를 들어 애니메이션의 일부는 어드바이저가 그리고 일부는 엔진이 그린다면) 부하가 거의 제거될 것입니다. 생각해야지...
그래서 그들은 당신이 말한대로 정확하게 다시 그려집니다.
그리고 프로세서의 로드는 애니메이션 중에 발생합니다.
여기에 픽셀 배열의 값이 지속적으로 재초기화됩니다. 16밀리초마다. 이것은 프로세서를 최대 40%까지 로드합니다.
나는 정확히 무엇이로드되는지 이해하려고 노력했습니다. 리소스를 저장하거나 읽을 생각입니다. 드로잉 루프에서 배열의 재초기화로 밝혀졌습니다.
또한 ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1); (16밀리초마다) 프로세서도 로드합니다. 약 10%.
이 호출을 사용하여 애니메이션 데이터가 있는 리소스를 읽어야 한다고 다른 EA에 알립니다.
전체적으로 애니메이션 중에 프로세서 부하의 + ~ 50%가 됩니다.
죄송합니다. 미결 거래 목록에 대해 더 이상 이야기하지 않는다는 사실을 몰랐습니다. 사라진 것, 주제의 2-3 페이지.
아니, 괜찮아. 방금 어드바이저와 엔진 간의 연결을 다시 실행하기 때문에 프로세서의 부하에 대해 이야기했습니다. 즉, 미결 거래 테이블도 데이터를 다르게 수신하게 됩니다.
왜 peridrawing 초당 64프레임(16ms), 초당 32프레임이 눈에 충분합니까?
좋은 질문. 실제로 타이머가 원활하게 작동하지 않습니다. 틈이 있습니다. 16,32,16,16...
32를 사용하는 경우 간격은 64ms가 됩니다. 그리고 이것은 눈에 띕니다. 또한 다양한 다른 것들도 로드되고 그리기 속도가 느려집니다. 예를 들어 OnChartEvent() 이벤트 대기열입니다.
나는 이것이 애니메이션 의 품질에 영향을 미친다고 생각합니다. 25ms를 사용해 보았습니다. 그런 다음 16, 16이 부드러운 움직임을 더 잘 전달한다는 결론에 도달했습니다.
나중에 애니메이션 16ms 및 32ms로 엔진을 끄면 직접 확인할 수 있습니다. 괜찮을지 모르지만...
좋은 질문. 실제로 타이머가 원활하게 작동하지 않습니다. 틈이 있습니다. 16,32,16,16...
32를 사용하는 경우 간격은 64ms가 됩니다. 그리고 이것은 눈에 띕니다. 또한 다양한 다른 것들도 로드되고 그리기 속도가 느려집니다. 예를 들어 OnChartEvent() 이벤트 대기열입니다.
나는 이것이 애니메이션의 품질에 영향을 미친다고 생각합니다. 25ms를 사용해 보았습니다. 그런 다음 16, 16이 부드러운 움직임을 더 잘 전달한다는 결론에 도달했습니다.
나중에 16ms와 32ms의 애니메이션으로 엔진을 끄면 직접 확인할 수 있습니다. 괜찮을지 모르지만...
실제로는 16ms가 아니라 1000/64=15.625ms입니다. 따라서 32ms가 아닌 30ms로 설정하는 것이 좋습니다. 그러면 간격이 줄어듭니다. 저것들. 프레임 사이의 일시 중지가 33ms로 설정된 경우 실제 일시 중지는 15.625×3=46.875ms가 됩니다.
왜요? 그냥 궁금합니다.
왜요? 그냥 궁금합니다.
실제로 16ms가 아니라 1000/64=15.625ms입니다. 따라서 32ms가 아닌 30ms로 설정하는 것이 좋습니다. 그러면 간격이 줄어듭니다. 저것들. 프레임 사이의 일시 중지가 33ms로 설정된 경우 실제 일시 중지는 15.625×3=46.875ms가 됩니다.
알겠습니다. 배우겠습니다.
물론 타이머의 주파수를 줄이면 프로세서의 부하가 줄어듭니다. 애니메이션 의 품질을 저하시키지 않는다면 훌륭합니다. 프로세서의 부하를 최대 30%까지 줄일 수 있지만 여전히 유지됩니다.
참아야 할 것입니다.
사실, 그림이 서로 다른 스레드 사이에 배포된다면(예를 들어 애니메이션의 일부는 어드바이저가 그리고 일부는 엔진이 그린다면) 부하가 거의 제거될 것입니다. 생각해야지...
아아, 내 가정은 확인되지 않았습니다.
이제 저는 실험을 했습니다. 두 개의 차트에 하나의 Expert Advisor를 배치했습니다. 어드바이저는 프로세서를 50% 로드합니다.
다른 차트로 작업해도 프로세서의 부하가 합산되어 MT에서 프로세서의 전체 부하가 90% 이상에 도달한 것으로 나타났습니다.
이것은 서로 다른 Expert Advisors간에 그림을 나누는 것조차도 도움이되지 않는다는 것을 의미합니다. 부하가 누적됩니다!
아아, 내 가정은 확인되지 않았습니다.
이제 저는 실험을 했습니다. 두 개의 차트에 하나의 Expert Advisor를 배치했습니다. EA는 프로세서에 50%를 로드합니다.
다른 차트로 작업해도 프로세서의 부하가 합산되어 MT에서 프로세서의 전체 부하가 90% 이상에 도달한 것으로 나타났습니다.
이것은 서로 다른 Expert Advisors간에 그림을 나누는 것조차도 도움이되지 않는다는 것을 의미합니다. 부하가 누적됩니다!