帆布与标签 - 页 7

新评论
 
Mihail Matkovskij:

是否有任何信息可以让你在某个地方读到更多关于这个的信息？虽然我很清楚，但这仍然是一个有趣的话题！我想这是一个很好的例子。现在只剩下做位图更新控制变体和测试了。如果位图变成比标签更快，我会感到惊讶。

我承认，在标签很少的情况下，使用它们比kanvas有速度上的优势，因为BitMap是用C++填写的，不是用MQL5。然而，在画布上，文本的形成也不可能是一样的，因为文本BitMap的形成在两种情况下都是由赢家函数来完成的。我认为在Label的例子中，这些对象也被包裹着事件驱动的属性（它们可以用鼠标拖动），这使得它们的构造最终变得更加沉重。

 

关于Canvas的速度，有一个问题。


视频卡是内置在CPU中的。


像这样运行代码。

#include <fxsaber\Usage\Usage.mqh> // https://www.mql5.com/ru/code/33875

void OnInit()
{  
  USAGE::MinInterval = 100 * 1000; // 100 ms.
  
  EventSetMillisecondTimer((int)USAGE::MinInterval / 1000);  
}

void OnTimer()
{
  _USAGE // Расчет нагрузки.

  USAGE::GraphCreate(1200, 900, 200); // Вывели график нагрузки.
}

void OnDeinit( const int )
{
  USAGE::GraphDelete(); // Удалили график нагрузки.
}

简而言之，它衡量OnTimer每100毫秒执行多少时间。此外，它还在OnTimer内绘制了一个测量图。这就是它得到的结果。

它吃掉了15-20%。显然，这是一个缓慢的显卡。但问题是不同的。如果我开始用鼠标撸动价格图表（当按住鼠标左键并向左向右移动时），负载会增加两倍。它在上面的动画中清晰可见。这种特殊性的原因是什么？


再一次。如果你用鼠标移动价格图表，OnTimer需要两倍的时间。

 
fxsaber:

关于Canvas的速度，有一个问题。


视频卡是内置在CPU中的。


像这样运行代码。

简而言之，它衡量OnTimer每100毫秒执行多少时间。此外，它还在OnTimer内绘制了一个测量图。这就是它得到的结果。

它吃掉了15-20%。显然，这是一个缓慢的显卡。但问题是不同的。如果我开始用鼠标撸动价格图表（当按住鼠标左键并向左向右移动时），负载会增加两倍。它在上面的动画中清晰可见。这种特殊性的原因是什么？


再一次。如果你用鼠标移动价格图表，OnTimer需要两倍的时间。

很可能你的库有CHARTEVENT_CHART_CHANGE控件，以便在需要时改变画布的大小（如果图表大小发生了变化），但为了找到它，你需要运行非常慢的（到目前为止）异步函数ChartGet...
这导致了速度的下降。
对于MQ来说，将CHARTEVENT_CHART_CHANGE事件分离出来，做成单独的CHARTEVENT_CHART_SIZE_CHANGE，会更加合理。在CHARTEVENT_CHART_CHANGE事件中，有太多的东西：新条形图的出现、条形图的滚动、垂直价格比例的变化、窗口大小的调整。

 
Nikolai Semko:
很有可能的是，在少量的Labels中，他们的使用比Kanvas有速度优势，因为BitMap是用C++而不是MQL5填写的。然而，在画布上，文本的形成也不可能是一样的，因为文本BitMap的形成在两种情况下都是由赢家函数来完成的。我认为在Label的例子中，这些对象也被包裹着事件驱动的属性（它们可以用鼠标拖动），这使得它们的构造最终变得更加沉重。

的确，标签可以更快。要看图表中的数量是多少...做了一次更新检查，结果确实让人吃惊。如果我没记错的话，这个限制是取自悦目的最低帧率，24帧。得到了大约41毫秒的时间。对Kanvas进行限制，哦，奇迹，我很惊讶。与无休止地更新标签相比，它简直是在飞。但当我把同样的限制放在Labels上显示时，它甚至比基于Kanvas的显示快。但我不会先入为主，我将在以后介绍所有的测试结果。

 
fxsaber:

如果我开始用鼠标抽动价格图表（按住LK键左右移动），负载就会增加一倍。在上面的动画中，它是完全可见的。这种特殊性的原因是什么？

使用Windows事件模型--即使你快速移动鼠标，CPU上的负载也开始增加，无论哪个应用程序处于焦点状态。

SZY: 用Win10任务管理器检查...我不认为Win10极大地改变了事件模型，更可能是任务管理器的工作方式不同。

 
Nikolai Semko:

很可能你的库有CHARTEVENT_CHART_CHANGE控件，以便在需要时改变画布尺寸（如果图表尺寸已经改变），但为了找到它，你需要执行非常缓慢（到目前为止）的异步ChartGet函数...
这导致了刹车的发生。
对于MQ来说，将CHARTEVENT_CHART_CHANGE事件分离出来，做成单独的CHARTEVENT_CHART_SIZE_CHANGE，会更加合理。CHARTEVENT_CHART_CHANGE事件有很多内容：新条形图的出现、条形图的滚动、垂直价格比例的变化、窗口大小的调整。

这些都不在上面的代码中。

 
Igor Makanu:

在Windows事件模型 中--即使你快速移动鼠标，CPU负载也开始增加，无论哪个应用程序处于焦点位置。

ZS：我用Win10任务管理器检查了...在Win7中，如果我快速移动鼠标，负载就会增加 - 我怀疑Win10已经从根本上改变了事件模型，最可能的是任务管理器的工作方式不同。

谢谢，我不知道。令人惊讶的是，鼠标能够使MQL程序的速度减半。

ZS 只有我得到这个结果吗？
fxsaber:

它吃掉了15-20%。显然，显卡的速度很慢。

 
fxsaber:

谢谢你，我不知道。我很惊讶，一个鼠标能够使MQL程序的速度减半。

那么，有滞后的虱子之类的东西也是合理的。有这样一个事件模型 的HFT就像一个雷区。

 
fxsaber:

这些都不在上面的代码中。

是的，没有看到是内部图表。
从剖析来看，滚动图表时，刹车的来源是在这条线上。

用主动滚动进行剖析。

在没有滚动的情况下，用主动的鼠标运动进行分析（没有按下LKM）。

ZS：所以刹车的来源不是坎瓦，而是物体。

 
Mihail Matkovskij:

你也可以在图表上检查一下。然而，我认为在测试器中做这件事会更容易。

这是一个有缺陷的方法。特别是视觉测试仪有一个不同的延迟渲染模型，以免完全拖慢测试过程。

所以，正如你所说的，在标签中绘制文本比绘制OBJ_BITMAP_LABEL需要更多的时间。

我并没有这么说。

我指出了明显的错误，并解释了渲染系统的运作方式。

1234567891011121314...18
新评论