我的方法。核心是引擎。 - 页 125 1...118119120121122123124125126127128129130131132...184 新评论 Vladimir 2019.01.05 18:46 #1241 Реter Konow:因此，他们完全按照你说的重新绘制。 而处理器上的负载来自于动画。 像素阵列中的数值不断被重新初始化。每16毫秒。这使处理器的负载达到了40%。 我正试图弄清楚到底是什么负荷。我以为是保存资源或阅读资源。结果发现是绘图循环中数组的重新初始化问题。 结果还发现，不断调用ObjectSetInteger(0, "MT object",OBJPROP_SELECTED,1);（每16毫秒）也会加载处理器。约10%。 我用这个调用来告诉另一个EA读取动画数据的资源。 总的来说，它在动画制作过程中得到+~50%的CPU负载。 对不起，没有注意到这不再是关于开放交易的列表。消失了，我想，是2-3页的主题。 Реter Konow 2019.01.05 18:49 #1242 Vladimir: 对不起，没有注意到这不再是关于开放交易的列表。走了，我想，2-3页的主题。不，这很好。我之所以提出CPU负载，是因为我打算重新做EA和引擎之间的通信，这意味着开放交易表也将采取不同的数据。 Nikolai Semko 2019.01.05 18:50 #1243 为什么需要每秒64帧（16ms），每秒32帧对眼睛来说已经足够。 Реter Konow 2019.01.05 19:16 #1244 Nikolai Semko: 为什么使periris每秒64帧（16毫秒），对于眼睛来说，每秒32帧就足够了。好问题。事实上，定时器的工作并不顺利。有跳板。16,32,16,16... 如果你使用32，跳过的时间是64ms。而这是很明显的。此外，其他各种事情也会给绘画带来负担和缓慢。例如，OnChartEvent()事件队列。 我认为这影响了动画的 质量。我试着用25毫秒。然后是16，得出的结论是16能更好地传达出平稳的运动。 后来skolnuyu引擎与动画16毫秒和32毫秒，你会看到自己。虽然，也许它将是OK.... Nikolai Semko 2019.01.05 19:39 #1245 Реter Konow:好问题。事实上，定时器的工作并不顺利。有跳板。16,32,16,16...如果你使用32，跳过的时间是64ms。而这是很明显的。此外，其他各种事情也会给绘画带来负担和缓慢。例如，OnChartEvent()事件队列。我认为这影响了动画的质量。我试着用25毫秒。然后是16，得出的结论是16能更好地传达出平稳的运动。后来skolnuyu引擎与动画16毫秒和32毫秒，你会看到自己。虽然，也许它将是OK.... 只是，这不是真正的16ms，而是1000/64=15.625ms。这就是为什么最好设置30毫秒而不是32毫秒，这样会有更少的跳过。即如果你把帧之间的暂停时间定为33毫秒，那么真正的暂停时间将是15.625×3=46.875毫秒。而且你必须记住，MT有它自己的内部图表更新处理程序，所以ChartRedraw 将以异步方式工作，而且不能保证MT会全部处理。 Алексей Тарабанов 2019.01.05 19:57 #1246 Nikolai Semko: 只是，这不是真正的16ms，而是1000/64=15.625ms。这就是为什么最好设置30毫秒而不是32毫秒，这样会有更少的跳过。即如果你把帧之间的暂停时间定为33毫秒，那么真正的暂停时间将是15.625×3=46.875毫秒。而且你必须记住，MT有它自己的内部图表更新处理程序，所以ChartRedraw将以异步方式工作，而且不能保证MT会全部处理。为什么？简单，有趣。 Nikolai Semko 2019.01.05 20:04 #1247 Алексей Тарабанов:为什么？简单，我想知道。 我只是在经过大量实验和科学试错后得出这些结论。如果有人有任何实验可以反驳我的说法，我将非常感激。 Реter Konow 2019.01.05 20:09 #1248 Nikolai Semko: 只是，这不是真正的16ms，而是1000/64=15.625ms。这就是为什么最好设置30毫秒而不是32毫秒，这样会有更少的跳过。即如果你把帧之间的暂停时间定为33毫秒，那么真正的暂停时间将是15.625×3=46.875毫秒。而且你必须记住，MT有它自己的内部图表更新处理程序，所以ChartRedraw将以异步方式工作，而且不能保证MT会全部处理。好的，我会考虑到这一点。 降低定时器频率肯定会减少处理器的负载。如果它不会降低动画的 质量，那就太好了。CPU负载可能会减少30%，但仍然会有。 你必须忍受它。 诚然，如果绘图分布在不同的线程之间，（例如部分动画绘制专家顾问，部分引擎），那么负载将几乎被移除。我们必须思考... Реter Konow 2019.01.05 20:26 #1249 唉，我的假设没有得到证实。 现在我做了一个实验--我把一个EA放在两个图表上。专家顾问对处理器的负载为50%。 我发现，即使在处理不同的图表时，CPU的负荷也是相加的，MT那边的CPU总负荷超过90%。 因此，即使在不同的专家顾问之间拆分图表也无济于事。负担越来越重了! Nikolai Semko 2019.01.05 20:30 #1250 Реter Konow:唉，我的假设没有得到证实。 现在我做了一个实验--我把一个EA放在两个图表上。专家顾问对处理器的负载为50%。 我发现，即使在处理不同的图表时，CPU的负荷也是相加的，MT那边的CPU总负荷超过90%。 因此，即使在不同的专家顾问之间拆分图表也无济于事。负担越来越重了! 如果是MT4，那么是的。据我所知，与MT4相比，MT5完全支持多核和多线程。 1...118119120121122123124125126127128129130131132...184 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
因此，他们完全按照你说的重新绘制。
而处理器上的负载来自于动画。
像素阵列中的数值不断被重新初始化。每16毫秒。这使处理器的负载达到了40%。
我正试图弄清楚到底是什么负荷。我以为是保存资源或阅读资源。结果发现是绘图循环中数组的重新初始化问题。
结果还发现，不断调用ObjectSetInteger(0, "MT object",OBJPROP_SELECTED,1);（每16毫秒）也会加载处理器。约10%。
我用这个调用来告诉另一个EA读取动画数据的资源。
总的来说，它在动画制作过程中得到+~50%的CPU负载。
对不起，没有注意到这不再是关于开放交易的列表。走了，我想，2-3页的主题。
不，这很好。我之所以提出CPU负载，是因为我打算重新做EA和引擎之间的通信，这意味着开放交易表也将采取不同的数据。
为什么使periris每秒64帧（16毫秒），对于眼睛来说，每秒32帧就足够了。
好问题。事实上，定时器的工作并不顺利。有跳板。16,32,16,16...
如果你使用32，跳过的时间是64ms。而这是很明显的。此外，其他各种事情也会给绘画带来负担和缓慢。例如，OnChartEvent()事件队列。
我认为这影响了动画的 质量。我试着用25毫秒。然后是16，得出的结论是16能更好地传达出平稳的运动。
后来skolnuyu引擎与动画16毫秒和32毫秒，你会看到自己。虽然，也许它将是OK....
好问题。事实上，定时器的工作并不顺利。有跳板。16,32,16,16...
如果你使用32，跳过的时间是64ms。而这是很明显的。此外，其他各种事情也会给绘画带来负担和缓慢。例如，OnChartEvent()事件队列。
我认为这影响了动画的质量。我试着用25毫秒。然后是16，得出的结论是16能更好地传达出平稳的运动。
后来skolnuyu引擎与动画16毫秒和32毫秒，你会看到自己。虽然，也许它将是OK....
只是，这不是真正的16ms，而是1000/64=15.625ms。这就是为什么最好设置30毫秒而不是32毫秒，这样会有更少的跳过。即如果你把帧之间的暂停时间定为33毫秒，那么真正的暂停时间将是15.625×3=46.875毫秒。
为什么？简单，有趣。
为什么？简单，我想知道。
只是，这不是真正的16ms，而是1000/64=15.625ms。这就是为什么最好设置30毫秒而不是32毫秒，这样会有更少的跳过。即如果你把帧之间的暂停时间定为33毫秒，那么真正的暂停时间将是15.625×3=46.875毫秒。
好的，我会考虑到这一点。
降低定时器频率肯定会减少处理器的负载。如果它不会降低动画的 质量，那就太好了。CPU负载可能会减少30%，但仍然会有。
你必须忍受它。
诚然，如果绘图分布在不同的线程之间，（例如部分动画绘制专家顾问，部分引擎），那么负载将几乎被移除。我们必须思考...
唉，我的假设没有得到证实。
现在我做了一个实验--我把一个EA放在两个图表上。专家顾问对处理器的负载为50%。
我发现，即使在处理不同的图表时，CPU的负荷也是相加的，MT那边的CPU总负荷超过90%。
因此，即使在不同的专家顾问之间拆分图表也无济于事。负担越来越重了!
唉，我的假设没有得到证实。
现在我做了一个实验--我把一个EA放在两个图表上。专家顾问对处理器的负载为50%。
我发现，即使在处理不同的图表时，CPU的负荷也是相加的，MT那边的CPU总负荷超过90%。
因此，即使在不同的专家顾问之间拆分图表也无济于事。负担越来越重了!