在Canvas上做一个众包项目 - 页 33 1...262728293031323334353637383940...45 新评论 Roman 2020.01.26 14:48 #321 Реter Konow: 在这个例子中,刷新率是正常的。这就是为什么它没有放慢速度。 在任务管理器中,我看到Metatrader(32位)。 可能你的滞后原因与你的系统的比特大小有关? 因为Metatrader现在只为x64设计。 而据开发者称,32位版本将不再发布。 异步数据处理的问题是否已经解决? Алексей Барбашин 2020.01.26 15:12 #322 Roman: 我在任务管理器中看到Metatrader(32位)。 也许,速度慢的原因是与你的系统的数字容量有关? 好吧,Metatrader现在只打算用于x64。 而据开发者称,32位版本将不再发布。 而异步数据处理的问题是否已经解决? 我确认我提到的Nikolai的例子在移动例子中的任何对象时确实会加载CPU,尤其是在快速移动时。负荷增加35-40%。该测试是在64位处理器、64位Windows 7和64位MT5上进行的。 在我们的讨论中,异步处理是什么意思? Реter Konow 2020.01.26 15:26 #323 Roman: 我可以在任务管理器中看到Metatrader(32位)。 也许,你的滞后的原因在于系统的位数容量? 事实上,Metatrader现在只为x64定制。 而据开发者称,32位版本将不再发布。 而异步数据处理的问题是否已经解决? 所有这些例子都是在MT4上。 MT5拉得更多,但在重绘不正确的情况下(如杯子)也会加载处理器(我检查过)。问题出在重绘的频率和面积上,应该通过一切手段减少重绘。如果你需要重绘一个单元格,那么它就是唯一的单元格。否则就是浪费资源,(例如,如果一个单元格每秒需要重绘10次,那么重绘整个画布就会 "杀死 "处理器,这是不现实的)。然而,这已经很清楚了。 让我解释一下。一个表格单元格有三个对象--基础、文本和图标。如果一个单元格的内容发生变化,我们需要在画布上做三次循环。在第一个周期,我们重新绘制底座,在第二个周期 - 文本,在第三个周期 - 图标。这就像我们把细胞的面积扩大了三倍。如果你一直以这种方式重绘整个画布,你会得到一个严重的减速。因此,有必要考虑到要重绘的画布区域的周期数量。你可能在简单的基元中看不到它,但它在复杂的元素中变得很明显。有些元素由10个对象组成(一个 带按钮的输入框 或一个输出列表或一个窗口平台),有可能计算出在重绘它们时应该在kanvas阵列上做多少个循环。幸运的是,这种重绘并不要求高重复率。 异步处理的问题还没有得到解决。有一些想法,但还没有找到解决办法。 总的来说,如果我们要在画布上创建一个GUI,我们应该用单独的可重绘元素来制作它。否则,程序将很快达到极限,之后简单操作的滞后将很明显。 Roman 2020.01.26 15:39 #324 Алексей Барбашин: 在我们的讨论中,异步数据处理是什么意思? 那么,按照我的理解,用简单的话说,就是异步(追逐资源)或多线程(专用资源)。 我没有看Nikolay的例子的代码,但由于Metatrader 中没有异步和多线程,像素重绘代码是同步执行 的。 而Petera的输出数据处理很可能也是同步进行的。而在这两种情况下,很可能所有这些仍然是在循环中处理的。 这增加了处理器的负载。为了在每次负载较少的情况下实现快速响应,数据处理和重绘应该是并列的。 Реter Konow 2020.01.26 15:48 #325 Roman: 那么,按照我的理解,用简单的话说,就是异步(资源争夺)或多线程(专用资源)。 我没有看Nikolay的例子的代码,但由于Metatrader 中没有异步和多线程,像素重绘代码是同步执行 的。而Petera的输出数据处理很可能也是同步进行的。而 在这两种情况下,所有这些都有可能被循环处理。 这 增加了处理器的负荷。为了在每次负载较少的情况下实现快速响应,数据处理和重绘应该是并列的。 并非如此))。让我澄清一下:我让引擎通过一个资源连接到用户应用程序。也就是说,--用户应用程序在其线程中进行计算,并将数据传递给引擎(携带GUI),引擎可能在不同的图形上。它处理参数事件并将其输出到GUI。换句话说,处理过程被分成了两个线程。然而,在我将要发布的构造函数中,情况就不是这样了。该应用程序将包括自身内部的引擎,一切都将在一个线程中。但处理器上的负载将是相同的。速度对函数序列的依赖性会越来越高。 Maxim Kuznetsov 2020.01.26 16:04 #326 Реter Konow: 并非如此))。让我澄清一下:我让引擎通过一个资源连接到用户应用程序。也就是说,--用户应用程序在其线程中进行计算,并将数据传递给引擎(携带GUI),引擎可能在不同的图形上。它处理参数事件并将其输出到GUI。换句话说,处理过程被分成了两个线程。然而,在 我将要发布的 构造函数中,情况就不是这样了。该应用程序将包括自身内部的引擎,一切都将在一个线程中。但处理器上的负载将是相同的。速度对执行功能的顺序的依赖性会越来越高。 我们又来了......承诺、公告、唠叨。 甚至已经忘记了 - "kernel-engine "是作为一个体面的软件发布的吗? 还是作为评论中的附件形式的垃圾? Алексей Барбашин 2020.01.26 16:11 #327 Roman: 那么,按照我的简单理解,异步(资源竞争)或多线程(专用资源)。 我没有看Nikolai的例子代码,但由于Metatrader 中没有异步和多线程,像素重绘代码是同步执行 的。 而Petera的输出数据处理很可能也是同步进行的。而在这两种情况下,所有这些都有可能被循环处理。 这 增加了处理器的负荷。为了在每次负载较少的情况下实现快速响应,数据处理和重绘应该是并列的。 MT中的所有操作都是严格的同步操作,除非开发者在应用程序中增加线程,否则这一点是无法真正改变的。 令人相当惊讶的是,开发人员正试图在与数据库、与Python、与Sharpe.Net合作方面扩展MT功能。但他们提出要在同一条线上进行......这实在是太神奇了。 Реter Konow 2020.01.26 16:12 #328 Maxim Kuznetsov: 我们又来了......承诺、公告、唠叨 我甚至忘了,"内核引擎 "是作为一个体面的软件发布的吗? 还是作为垃圾,作为评论的附件发布的? 对你有好处。我从与你这样的人的斗争中获得灵感,而他们总是输。)你在给我能量,而你没有意识到这一点。 Алексей Барбашин 2020.01.26 16:13 #329 Maxim Kuznetsov: 我们又来了......承诺、公告、唠叨 我甚至忘了,"内核引擎 "是作为一个体面的软件发布的吗? 还是作为评论中的附件形式的垃圾发布的? 马克斯,要谨慎。 Roman 2020.01.26 16:17 #330 Реter Konow: 并非如此))。让我澄清一下:我让引擎通过一个资源连接到用户应用程序。也就是说,--用户应用程序在其线程中进行计算,并将数据传递给引擎(携带GUI),引擎可能在不同的图形上。它处理参数事件并将其输出到GUI。换句话说,处理过程被分成了两个线程。然而,在我将要发布的构造函数中,情况就不是这样了。该应用程序将包括自身内部的引擎,一切都将在一个线程中。但处理器上的负载将是相同的。只是,速度对函数序列的依赖性会更大。 我明白这一点,应用程序分开,GUI分开。 但无论如何,GUI中对输出数据的处理是同步进行的。 例如,应用程序向GUI发送10000个元素,GUI按顺序处理所有这些元素。 这就是问题所在。 有必要在GUI中对传入的元素及其输出进行并行处理。基础、文本、图标。 更有甚者,每个细胞有三个循环。 1...262728293031323334353637383940...45 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
在这个例子中,刷新率是正常的。这就是为什么它没有放慢速度。
在任务管理器中,我看到Metatrader(32位)。
异步数据处理的问题是否已经解决?可能你的滞后原因与你的系统的比特大小有关?
因为Metatrader现在只为x64设计。
而据开发者称,32位版本将不再发布。
我在任务管理器中看到Metatrader(32位)。
而异步数据处理的问题是否已经解决?也许,速度慢的原因是与你的系统的数字容量有关?
好吧,Metatrader现在只打算用于x64。
而据开发者称,32位版本将不再发布。
我确认我提到的Nikolai的例子在移动例子中的任何对象时确实会加载CPU,尤其是在快速移动时。负荷增加35-40%。该测试是在64位处理器、64位Windows 7和64位MT5上进行的。
在我们的讨论中,异步处理是什么意思?
我可以在任务管理器中看到Metatrader(32位)。
而异步数据处理的问题是否已经解决?也许,你的滞后的原因在于系统的位数容量?
事实上,Metatrader现在只为x64定制。
而据开发者称,32位版本将不再发布。
所有这些例子都是在MT4上。
MT5拉得更多,但在重绘不正确的情况下(如杯子)也会加载处理器(我检查过)。问题出在重绘的频率和面积上,应该通过一切手段减少重绘。如果你需要重绘一个单元格,那么它就是唯一的单元格。否则就是浪费资源,(例如,如果一个单元格每秒需要重绘10次,那么重绘整个画布就会 "杀死 "处理器,这是不现实的)。然而,这已经很清楚了。
让我解释一下。一个表格单元格有三个对象--基础、文本和图标。如果一个单元格的内容发生变化,我们需要在画布上做三次循环。在第一个周期,我们重新绘制底座,在第二个周期 - 文本,在第三个周期 - 图标。这就像我们把细胞的面积扩大了三倍。如果你一直以这种方式重绘整个画布,你会得到一个严重的减速。因此,有必要考虑到要重绘的画布区域的周期数量。你可能在简单的基元中看不到它,但它在复杂的元素中变得很明显。有些元素由10个对象组成(一个 带按钮的输入框 或一个输出列表或一个窗口平台),有可能计算出在重绘它们时应该在kanvas阵列上做多少个循环。幸运的是,这种重绘并不要求高重复率。
异步处理的问题还没有得到解决。有一些想法,但还没有找到解决办法。
总的来说,如果我们要在画布上创建一个GUI,我们应该用单独的可重绘元素来制作它。否则,程序将很快达到极限,之后简单操作的滞后将很明显。
在我们的讨论中,异步数据处理是什么意思?
那么,按照我的理解,用简单的话说,就是异步(追逐资源)或多线程(专用资源)。
我没有看Nikolay的例子的代码,但由于Metatrader 中没有异步和多线程,像素重绘代码是同步执行 的。
而Petera的输出数据处理很可能也是同步进行的。而在这两种情况下,很可能所有这些仍然是在循环中处理的。
这增加了处理器的负载。为了在每次负载较少的情况下实现快速响应,数据处理和重绘应该是并列的。
那么,按照我的理解,用简单的话说,就是异步(资源争夺)或多线程(专用资源)。
我没有看Nikolay的例子的代码,但由于Metatrader 中没有异步和多线程,像素重绘代码是同步执行 的。
而Petera的输出数据处理很可能也是同步进行的。而 在这两种情况下,所有这些都有可能被循环处理。
这 增加了处理器的负荷。为了在每次负载较少的情况下实现快速响应,数据处理和重绘应该是并列的。
并非如此))。让我澄清一下:我让引擎通过一个资源连接到用户应用程序。也就是说,--用户应用程序在其线程中进行计算,并将数据传递给引擎(携带GUI),引擎可能在不同的图形上。它处理参数事件并将其输出到GUI。换句话说,处理过程被分成了两个线程。然而,在我将要发布的构造函数中,情况就不是这样了。该应用程序将包括自身内部的引擎,一切都将在一个线程中。但处理器上的负载将是相同的。速度对函数序列的依赖性会越来越高。
并非如此))。让我澄清一下:我让引擎通过一个资源连接到用户应用程序。也就是说,--用户应用程序在其线程中进行计算,并将数据传递给引擎(携带GUI),引擎可能在不同的图形上。它处理参数事件并将其输出到GUI。换句话说,处理过程被分成了两个线程。然而,在 我将要发布的 构造函数中,情况就不是这样了。该应用程序将包括自身内部的引擎,一切都将在一个线程中。但处理器上的负载将是相同的。速度对执行功能的顺序的依赖性会越来越高。
我们又来了......承诺、公告、唠叨。
甚至已经忘记了 - "kernel-engine "是作为一个体面的软件发布的吗? 还是作为评论中的附件形式的垃圾?
那么,按照我的简单理解,异步(资源竞争)或多线程(专用资源)。
我没有看Nikolai的例子代码,但由于Metatrader 中没有异步和多线程,像素重绘代码是同步执行 的。
而Petera的输出数据处理很可能也是同步进行的。而在这两种情况下,所有这些都有可能被循环处理。
这 增加了处理器的负荷。为了在每次负载较少的情况下实现快速响应,数据处理和重绘应该是并列的。
MT中的所有操作都是严格的同步操作,除非开发者在应用程序中增加线程,否则这一点是无法真正改变的。
令人相当惊讶的是,开发人员正试图在与数据库、与Python、与Sharpe.Net合作方面扩展MT功能。但他们提出要在同一条线上进行......这实在是太神奇了。
我们又来了......承诺、公告、唠叨
我甚至忘了,"内核引擎 "是作为一个体面的软件发布的吗? 还是作为垃圾,作为评论的附件发布的?
对你有好处。我从与你这样的人的斗争中获得灵感,而他们总是输。)你在给我能量,而你没有意识到这一点。
我们又来了......承诺、公告、唠叨
我甚至忘了,"内核引擎 "是作为一个体面的软件发布的吗? 还是作为评论中的附件形式的垃圾发布的?
马克斯,要谨慎。
并非如此))。让我澄清一下:我让引擎通过一个资源连接到用户应用程序。也就是说,--用户应用程序在其线程中进行计算,并将数据传递给引擎(携带GUI),引擎可能在不同的图形上。它处理参数事件并将其输出到GUI。换句话说,处理过程被分成了两个线程。然而,在我将要发布的构造函数中,情况就不是这样了。该应用程序将包括自身内部的引擎,一切都将在一个线程中。但处理器上的负载将是相同的。只是,速度对函数序列的依赖性会更大。
我明白这一点,应用程序分开,GUI分开。
但无论如何,GUI中对输出数据的处理是同步进行的。
例如,应用程序向GUI发送10000个元素,GUI按顺序处理所有这些元素。
这就是问题所在。 有必要在GUI中对传入的元素及其输出进行并行处理。基础、文本、图标。
更有甚者,每个细胞有三个循环。