文章 "图形界面 X: 标准图表控件 (集成编译 4)" - 页 3 123456 新评论 Реter Konow 2016.10.27 10:49 #21 Anatoli Kazharski:你错了。我已经在上面的评论中详细回答了为什么要这样做。现在它不会占用大量资源（Windows 10 也是如此）。你读过这篇文章（以及评论）吗？//---附注： 顺便说一下，在同等条件下，不同终端（MT4/MT5）和操作系统版本（Windows）的 CPU 资源消耗是完全不同的。在Windows 7 中，MetaTrader 4 终端的性能明显优于MetaTrader 5。遗憾的是，我现在无法提供相关数据，因为我已经完全切换到Windows 10。至于优化，我还没有用尽所有选项。还有一些需要优化的地方，我也知道如何优化。要实现加速滚动和流畅更改光标下对象的颜色，需要一个计时器。这里一切正常。但在空闲状态下，它不能造成高达 10% 的资源消耗。所以问题出在别处。什么问题呢？Возможно проблема в вызове функции CheckElementsEventsTimer(), каждые 16 мс?也就是说，在每个定时器事件发生时，都要检查所有界面元素的事件？为什么？这种检查有什么会给处理器带来负荷？ Anatoli Kazharski 2016.10.27 10:52 #22 例如，在干净的图表区域内移动鼠标光标，如果上面什么都没有（图形对象和 MQL 应用程序），CPU 消耗就会增加6-7%：测试前测试期间 Anatoli Kazharski 2016.10.27 10:59 #23 Реter Konow:要实现加速滚动，并平滑地改变光标下对象的颜色，就需要一个计时器。这里一切正常。但在空闲状态下，它不能导致高达 10% 的资源消耗。所以问题出在别处。什么问题呢？也就是说，在每个定时器事件发生时，都要检查所有界面元素的事件？为什么？现在只需在移动光标时执行。而这只是在Windows 10 中。在Windows 7 中并非如此。 如果使用您建议的方法，那么将花费同样的成本为光标所在的元素准备一个数组，而且还会出现其他问题。我已经测试过这种方法，但还是放弃了，因为没有任何实际的好处。还有其他一些选择，但仍需测试。如果有收获，将在下一篇文章中介绍。 Реter Konow 2016.10.27 11:01 #24 Anatoli Kazharski:例如，在干净的图表区域内移动鼠标光标，如果上面什么都没有（图形对象和 MQL 应用程序），CPU 消耗就会增加6-7%：测试前：测试期间遗憾的是，这一事实无法优化。不过，在定时器事件中检查控制元件 的状态（我认为太频繁了，可以用 25 毫秒代替 16 毫秒），如果在检查过程中不执行消耗资源的操作，就不会以任何方式增加资源消耗。 Anatoli Kazharski 2016.10.27 11:01 #25 Реter Konow:...这项测试会给处理器带来什么压力？...不过，在定时器事件中检查控制元件的状态（我认为频率太高了，可以设置 25 毫秒，而不是 16 毫秒）不会以任何方式增加资源消耗、 如果在检查期间没有执行消耗资源的操作。 重新绘制图表 以显示变化。 Реter Konow 2016.10.27 11:10 #26 Anatoli Kazharski:现在，只有在移动光标时才会这样做。这仅适用于Windows 10。在Windows 7 中，情况并非如此。 如果使用您建议的方法，那么将花费同样的成本来准备一个数组，其中包含光标现在所处位置的元素以及其他一些问题。 我已经测试过这种方法，但还是放弃了，因为没有任何实际的好处。还有其他一些选择，但仍需测试。如果有收获，将在下一篇文章中介绍。1.在这里，你已经错了。准备带有元素坐标和大小的映射数组，以及在移动窗口时调整其值，并不会显著增加处理器的负载，因为只有在移动光标和抓住窗口句柄时才 会进行这些工作。如果光标发生其他移动，则不会调用坐标重新计算功能。2.2. 如果只是移动光标，则会调用 定位器函数，该函数 将在元素图中循环，并找到光标下的对象。这个过程纯粹是计算性的，不会加载处理器。 Anatoli Kazharski 2016.10.27 11:16 #27 Реter Konow: 准备一个包含元素坐标和大小的映射数组，以及在窗口移动事件中修正其值，并不会显著增加处理器的负载，因为这些工作仅在光标移动事件中以及在抓取窗口句柄时才会完成。这就是为什么这样做毫无意义。我们的目标不是增加处理器的负载，即使是微不足道的负载，而是减少负载。事实证明，我没有弄错。) Реter Konow 2016.10.27 11:18 #28 Anatoli Kazharski: 重新绘制图表 以显示变化。既然可以逐点对特定元素进行更改，为什么还要重绘整个图表呢？您可以每隔 16 毫秒检查一次更改的必要性（检查不加载），但只有在必要时才将更改应用于每个特定对象，而不是重绘整个图表。 Anatoli Kazharski 2016.10.27 11:31 #29 Реter Konow:既然可以逐点对特定元素进行更改，为什么还要重绘整个图表呢？每次对图表进行更改后，您都需要调用ChartRedraw() 函数以即时显示。这同样适用于在画布上绘图。因此，首先要对所有元素进行更改，然后才能重新绘制图表。Konow 标签：您可以每隔 16 毫秒检查一次更改的必要性（检查不加载），但只有在必要时才将更改应用于每个特定对象，而不会重绘整个图表。现在每 16 毫秒重绘一次的情况根本不存在。用户又不会不停地用鼠标光标在图表上切圆。在目前的实现中，CPU 资源消耗不会超过6-7%。 Реter Konow 2016.10.27 11:40 #30 Anatoli Kazharski:每次对图表进行更改后，必须调用ChartRedraw() 函数才能即时显示。这同样适用于在画布上绘图。这就是为什么要先对所有元素进行更改，然后才重新绘制图表。这非常非常奇怪。在我的接口实现中，没有一次调用ChartRedraw() 函数。直到现在我才真正知道为什么需要它.....我使用画布（位图对象）时不需要它。让我们假设ChartRedraw() 函数是必要的，--那么事实证明，每个对象的每次更改都需要对所有对象进行完全重绘？ 123456 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
你错了。我已经在上面的评论中详细回答了为什么要这样做。
现在它不会占用大量资源（Windows 10 也是如此）。你读过这篇文章（以及评论）吗？
//---
附注： 顺便说一下，在同等条件下，不同终端（MT4/MT5）和操作系统版本（Windows）的 CPU 资源消耗是完全不同的。在Windows 7 中，MetaTrader 4 终端的性能明显优于MetaTrader 5。遗憾的是，我现在无法提供相关数据，因为我已经完全切换到Windows 10。
至于优化，我还没有用尽所有选项。还有一些需要优化的地方，我也知道如何优化。
要实现加速滚动和流畅更改光标下对象的颜色，需要一个计时器。这里一切正常。
但在空闲状态下，它不能造成高达 10% 的资源消耗。所以问题出在别处。什么问题呢？
也就是说，在每个定时器事件发生时，都要检查所有界面元素的事件？为什么？
这种检查有什么会给处理器带来负荷？
例如，在干净的图表区域内移动鼠标光标，如果上面什么都没有（图形对象和 MQL 应用程序），CPU 消耗就会增加6-7%：
测试前
测试期间
要实现加速滚动，并平滑地改变光标下对象的颜色，就需要一个计时器。这里一切正常。
但在空闲状态下，它不能导致高达 10% 的资源消耗。所以问题出在别处。什么问题呢？
也就是说，在每个定时器事件发生时，都要检查所有界面元素的事件？为什么？
现在只需在移动光标时执行。而这只是在Windows 10 中。在Windows 7 中并非如此。
如果使用您建议的方法，那么将花费同样的成本为光标所在的元素准备一个数组，而且还会出现其他问题。我已经测试过这种方法，但还是放弃了，因为没有任何实际的好处。
还有其他一些选择，但仍需测试。如果有收获，将在下一篇文章中介绍。
例如，在干净的图表区域内移动鼠标光标，如果上面什么都没有（图形对象和 MQL 应用程序），CPU 消耗就会增加6-7%：
测试前：
测试期间
遗憾的是，这一事实无法优化。
不过，在定时器事件中检查控制元件 的状态（我认为太频繁了，可以用 25 毫秒代替 16 毫秒），如果在检查过程中不执行消耗资源的操作，就不会以任何方式增加资源消耗。
...
这项测试会给处理器带来什么压力？
...
不过，在定时器事件中检查控制元件的状态（我认为频率太高了，可以设置 25 毫秒，而不是 16 毫秒）不会以任何方式增加资源消耗、
如果在检查期间没有执行消耗资源的操作。
现在，只有在移动光标时才会这样做。这仅适用于Windows 10。在Windows 7 中，情况并非如此。
如果使用您建议的方法，那么将花费同样的成本来准备一个数组，其中包含光标现在所处位置的元素以及其他一些问题。 我已经测试过这种方法，但还是放弃了，因为没有任何实际的好处。
还有其他一些选择，但仍需测试。如果有收获，将在下一篇文章中介绍。
1.在这里，你已经错了。准备带有元素坐标和大小的映射数组，以及在移动窗口时调整其值，并不会显著增加处理器的负载，因为只有在移动光标和抓住窗口句柄时才 会进行这些工作。如果光标发生其他移动，则不会调用坐标重新计算功能。
2.2. 如果只是移动光标，则会调用 定位器函数，该函数 将在元素图中循环，并找到光标下的对象。这个过程纯粹是计算性的，不会加载处理器。
Реter Konow:
准备一个包含元素坐标和大小的映射数组，以及在窗口移动事件中修正其值，并不会显著增加处理器的负载，因为这些工作仅在光标移动事件中以及在抓取窗口句柄时才会完成。
这就是为什么这样做毫无意义。我们的目标不是增加处理器的负载，即使是微不足道的负载，而是减少负载。事实证明，我没有弄错。)
重新绘制图表 以显示变化。
既然可以逐点对特定元素进行更改，为什么还要重绘整个图表呢？
您可以每隔 16 毫秒检查一次更改的必要性（检查不加载），但只有在必要时才将更改应用于每个特定对象，而不是重绘整个图表。
既然可以逐点对特定元素进行更改，为什么还要重绘整个图表呢？
每次对图表进行更改后，您都需要调用ChartRedraw() 函数以即时显示。这同样适用于在画布上绘图。因此，首先要对所有元素进行更改，然后才能重新绘制图表。
Konow 标签：
您可以每隔 16 毫秒检查一次更改的必要性（检查不加载），但只有在必要时才将更改应用于每个特定对象，而不会重绘整个图表。
现在每 16 毫秒重绘一次的情况根本不存在。用户又不会不停地用鼠标光标在图表上切圆。在目前的实现中，CPU 资源消耗不会超过6-7%。
每次对图表进行更改后，必须调用ChartRedraw() 函数才能即时显示。这同样适用于在画布上绘图。这就是为什么要先对所有元素进行更改，然后才重新绘制图表。
这非常非常奇怪。在我的接口实现中，没有一次调用ChartRedraw() 函数。
直到现在我才真正知道为什么需要它.....我使用画布（位图对象）时不需要它。
让我们假设ChartRedraw() 函数是必要的，--那么事实证明，每个对象的每次更改都需要对所有对象进行完全重绘？