在Canvas上做一个众包项目 - 页 33

新评论
 
Реter Konow:

在这个例子中，刷新率是正常的。这就是为什么它没有放慢速度。

在任务管理器中，我看到Metatrader（32位）。
可能你的滞后原因与你的系统的比特大小有关？
因为Metatrader现在只为x64设计。
而据开发者称，32位版本将不再发布。

异步数据处理的问题是否已经解决？
 
Roman:

我在任务管理器中看到Metatrader（32位）。
也许，速度慢的原因是与你的系统的数字容量有关？
好吧，Metatrader现在只打算用于x64。
而据开发者称，32位版本将不再发布。

而异步数据处理的问题是否已经解决？

我确认我提到的Nikolai的例子在移动例子中的任何对象时确实会加载CPU，尤其是在快速移动时。负荷增加35-40%。该测试是在64位处理器、64位Windows 7和64位MT5上进行的。

在我们的讨论中，异步处理是什么意思？

 
Roman:

我可以在任务管理器中看到Metatrader（32位）。
也许，你的滞后的原因在于系统的位数容量？
事实上，Metatrader现在只为x64定制。
而据开发者称，32位版本将不再发布。

而异步数据处理的问题是否已经解决？

所有这些例子都是在MT4上。

MT5拉得更多，但在重绘不正确的情况下（如杯子）也会加载处理器（我检查过）。问题出在重绘的频率和面积上，应该通过一切手段减少重绘。如果你需要重绘一个单元格，那么它就是唯一的单元格。否则就是浪费资源，（例如，如果一个单元格每秒需要重绘10次，那么重绘整个画布就会 "杀死 "处理器，这是不现实的）。然而，这已经很清楚了。

让我解释一下。一个表格单元格有三个对象--基础、文本和图标。如果一个单元格的内容发生变化，我们需要在画布上做三次循环。在第一个周期，我们重新绘制底座，在第二个周期 - 文本，在第三个周期 - 图标。这就像我们把细胞的面积扩大了三倍。如果你一直以这种方式重绘整个画布，你会得到一个严重的减速。因此，有必要考虑到要重绘的画布区域的周期数量。你可能在简单的基元中看不到它，但它在复杂的元素中变得很明显。有些元素由10个对象组成（一个 带按钮的输入框 或一个输出列表或一个窗口平台），有可能计算出在重绘它们时应该在kanvas阵列上做多少个循环。幸运的是，这种重绘并不要求高重复率。

异步处理的问题还没有得到解决。有一些想法，但还没有找到解决办法。

总的来说，如果我们要在画布上创建一个GUI，我们应该用单独的可重绘元素来制作它。否则，程序将很快达到极限，之后简单操作的滞后将很明显。

 
Алексей Барбашин:

在我们的讨论中，异步数据处理是什么意思？

那么，按照我的理解，用简单的话说，就是异步（追逐资源）或多线程（专用资源）。
我没有看Nikolay的例子的代码，但由于Metatrader 中没有异步和多线程，像素重绘代码是同步执行 的。
而Petera的输出数据处理很可能也是同步进行的。而在这两种情况下，很可能所有这些仍然是在循环中处理的。
 这增加了处理器的负载。为了在每次负载较少的情况下实现快速响应，数据处理和重绘应该是并列的。

 
Roman:

那么，按照我的理解，用简单的话说，就是异步（资源争夺）或多线程（专用资源）。
我没有看Nikolay的例子的代码，但由于Metatrader 中没有异步和多线程，像素重绘代码是同步执行 的。
而Petera的输出数据处理很可能也是同步进行的。而 在这两种情况下，所有这些都有可能被循环处理。
这 增加了处理器的负荷。为了在每次负载较少的情况下实现快速响应，数据处理和重绘应该是并列的。

并非如此））。让我澄清一下：我让引擎通过一个资源连接到用户应用程序。也就是说，--用户应用程序在其线程中进行计算，并将数据传递给引擎（携带GUI），引擎可能在不同的图形上。它处理参数事件并将其输出到GUI。换句话说，处理过程被分成了两个线程。然而，在我将要发布的构造函数中，情况就不是这样了。该应用程序将包括自身内部的引擎，一切都将在一个线程中。但处理器上的负载将是相同的。速度对函数序列的依赖性会越来越高。

 
Реter Konow:

并非如此））。让我澄清一下：我让引擎通过一个资源连接到用户应用程序。也就是说，--用户应用程序在其线程中进行计算，并将数据传递给引擎（携带GUI），引擎可能在不同的图形上。它处理参数事件并将其输出到GUI。换句话说，处理过程被分成了两个线程。然而，在 我将要发布的 构造函数中，情况就不是这样了。该应用程序将包括自身内部的引擎，一切都将在一个线程中。但处理器上的负载将是相同的。速度对执行功能的顺序的依赖性会越来越高。

我们又来了......承诺、公告、唠叨。

甚至已经忘记了 - "kernel-engine "是作为一个体面的软件发布的吗？ 还是作为评论中的附件形式的垃圾？

 
Roman:

那么，按照我的简单理解，异步（资源竞争）或多线程（专用资源）。
我没有看Nikolai的例子代码，但由于Metatrader 中没有异步和多线程，像素重绘代码是同步执行 的。
而Petera的输出数据处理很可能也是同步进行的。而在这两种情况下，所有这些都有可能被循环处理。
这 增加了处理器的负荷。为了在每次负载较少的情况下实现快速响应，数据处理和重绘应该是并列的。

MT中的所有操作都是严格的同步操作，除非开发者在应用程序中增加线程，否则这一点是无法真正改变的。

令人相当惊讶的是，开发人员正试图在与数据库、与Python、与Sharpe.Net合作方面扩展MT功能。但他们提出要在同一条线上进行......这实在是太神奇了。

 
Maxim Kuznetsov:

我们又来了......承诺、公告、唠叨

我甚至忘了，"内核引擎 "是作为一个体面的软件发布的吗？ 还是作为垃圾，作为评论的附件发布的？

对你有好处。我从与你这样的人的斗争中获得灵感，而他们总是输。)你在给我能量，而你没有意识到这一点。

 
Maxim Kuznetsov:

我们又来了......承诺、公告、唠叨

我甚至忘了，"内核引擎 "是作为一个体面的软件发布的吗？ 还是作为评论中的附件形式的垃圾发布的？

马克斯，要谨慎。

 
Реter Konow:

并非如此））。让我澄清一下：我让引擎通过一个资源连接到用户应用程序。也就是说，--用户应用程序在其线程中进行计算，并将数据传递给引擎（携带GUI），引擎可能在不同的图形上。它处理参数事件并将其输出到GUI。换句话说，处理过程被分成了两个线程。然而，在我将要发布的构造函数中，情况就不是这样了。该应用程序将包括自身内部的引擎，一切都将在一个线程中。但处理器上的负载将是相同的。只是，速度对函数序列的依赖性会更大。

我明白这一点，应用程序分开，GUI分开。
但无论如何，GUI中对输出数据的处理是同步进行的。
例如，应用程序向GUI发送10000个元素，GUI按顺序处理所有这些元素。
这就是问题所在。 有必要在GUI中对传入的元素及其输出进行并行处理。基础、文本、图标。
更有甚者，每个细胞有三个循环。

1...262728293031323334353637383940...45
新评论