错误、漏洞、问题 - 页 976

新评论
 
我还将运行测试并写出结果。
 
voix_kas:

...

这很奇怪，我有相反的想法。

我得到了这个结果。

关于交易、自动交易系统和策略测试的论坛

错误, 漏洞, 问题

雷纳特, 2013.04.27 13:32

我也会做测试并把结果写出来。

这将是有趣的事情。
 

我完全忘记了，在测试标签时，绘图完全来自MQL5系统，并在界面线程中绘制。在MQL5中，只有标签描述被修改。

当绘制位图时，所有的绘制都是在MQL5内进行的，只有一个非常快速的单一BitBlt留在界面流中。

也就是说，测试是完全不正确的，因为标记映射根本没有被测试。图表刷新是一个异步命令，只向界面线程发送通知进行渲染。正如你从带有ChartRedraw 成本的截图中看到的那样。

 
Renat:
Argb_normalize最好不要使用，因为它给颜色正常化带来了额外的成本。最好是用纯色画简单的东西。

阿尔法通道有一种美学上的吸引力。当文字 "透明 "地显示在图形/球体之上时，可以得出的明显结论是，存在着用途的划分。

如果你只是想显示一个信息/统计信息，文本标签更快。 在创建控件（如按钮）的情况下--位图，而且没有选项。然后你就可以用纯色填充整个矩形区域，不需要阿尔法通道/透明度，不会有太多的挫折感。

 
voix_kas:

从循环中删除ChartRedraw()函数 是不正确的，因为文本标签属性变化的 "原子操作 "没有被终端的视频引擎处理。

是的，与视频引擎不处理数组工作的方式完全一样。

问题是要找出哪种方法更有效--改变位图或改变标签。

创建位图失去了 - 这是肯定的。

而在这两种情况下，图表的呈现是可以争论的、次要的。


只要想想结果就知道了。你看，每个周期更换标签的4秒????，这是无稽之谈。

标签的变化应该纯粹是为了检查变化，而不是为了干扰图表的渲染子系统。

否则，你会看到与位图相当的数字。

 
Renat:

我完全忘记了，在测试标签时，绘图完全来自MQL5系统，并在界面流程中绘制。在MQL5中，只有标签描述被修改。

在绘制位图时，所有的工作都是在MQL5中进行的。

但就速度而言，标签的变化仍然比位图快。因为GDI的功能很慢。

换句话说，测试是完全错误的，因为标记映射根本就没有被测试。图表刷新是一个异步命令，只向要绘制的界面线程发送通知。这就是你从截图中可以看到的ChartRedraw成本。

正是如此。


我认为我们需要在一些特定的繁重 任务下进行测试。谁会去做这样的基准任务？

- 使用一堆标签（矩形）和使用位图来绘制图形（例如正弦波）。
- 绘制excel表格（矩形+文本标签）和作为位图。

和其他选项，其中MT图形可以被位图取代。

检查资源消耗以支持一个位图和大量的MT 对象。+ 取决于要填充的区域的大小。

 

从标签测试中你可以看到的另一件事是，有一个非常经济的单向写操作，没有读标签。在这种情况下，每次写的命令流有最大的快速管道化（在这种情况下我们特意使用高效的系统）。

但如果你把写和读对象数据混在一起，在实际工作中经常出现这种情况，那么速度就会急剧下降。

更新：在标记测试的例子中，也有一个关键的错误--只有一个修改到一个标记上，而不是26个。请看一下来源。

 
Renat:

也就是说，这个测试是完全不正确的，因为它根本没有测试标签映射。

sergeev:

标签的变化应该是纯粹的变化测试，而不是图表渲染子系统被扫入。

当然，我是不同意的。论点：用户希望尽可能多地看到情况的变化（统计），在每一个刻度 上。因此，在更新统计数字之后，它们应该被显示出来=ChartRedraw()。

可以说，这是就表演的直接应用/实践性而言的。

至于真空中的球形基准--这是可选的。

 
sergeev:

但就速度而言，标记的变化仍然比位图快。因为GDI的功能很慢。

不，在修改标签时不会调用GDI方法。在μl5中的标签上完全没有渲染!
 
Renat:

在标签测试的例子中还有 一个关键错误 --只有一个标签被修改，而不是26个。 看看来源。

所有（一半）标签的文字都会改变，这些标签的目的是显示指标的值，而不是其描述。当你运行该脚本时，你可以看到。

要么我不理解你。我们特别讨论的是哪条线？

1...969970971972973974975976977978979980981982983...3184
新评论