用 MQL 编写的用户界面图库 - 页 53

新评论
 
hini #:
Rether，你能否考虑在今后的版本中将目录改为英文？包含目录名称的源代码文件已用文本替换。

当然可以。我已经考虑过了。我会制作一个包含英文目录名称的特别发布版本。

 

我没有检查文件，只检查了这里的评论。但对我来说，"滞后 "似乎与速度无关，而是与在完全创建新资源之前使用 ChartRedraw 有关。因为它会在空白画布上闪烁，然后显示新画布。

 
Реter Konow #:

当然可以。我已经考虑过了。我会制作一个包含英文目录名称的特别发布版本。

我的建议是不要有英文目录特别版本，而是只有一个这一个英文版本，仅仅是将目录名改为英文，下一步是将文件名改为英文，源代码你依然是用俄语编写。
至少我们其他人查看代码，只需要看文件名了解大概作用就行了。
 
hini #:
我建议不要制作包含英文目录的特别版本，而只制作一个这样的英文版本，只需将目录名称改为英文，下一步就是将文件名称改为英文，源代码仍用俄文编写。
至少，我们其他人在查看代码时只需查看文件名，就能知道它可能是做什么的。

我同意。我会逐渐改用英文命名目录。这样会更合理。

 
Samuel Manoel De Souza #:

我没有检查文件，只看了这里的评论。但对我来说，这种 "滞后 "似乎与速度无关，而是与在新资源完全创建之前使用 ChartRedraw 有关。因为它会闪烁一个空白画布，然后显示新画布。

有趣的想法，我会尝试测试一下。谢谢。

 

因此，更新...

这是一个临时更新。我将在几天后发布下一个版本。届时将有新的功能用于程序与控件的 交互。

我不得不说：我在两个版本上工作--2470 和新版本。大部分开发工作都是在旧版本上完成的。旧版本的编译速度更快--4 秒对 26-32 秒。新版的工作方式有些不同，而且很明显。有时快，有时慢。也许只是感觉而已。很难找到区别，但对我来说似乎是存在的。旧版本的界面飞快。在新版上几乎是飞。也许我觉得这是因为我已经习惯了。

不过，也有细微的差别。例如，在切换图表时，如果返回的图表高度和宽度值不正确，就会出现问题。这会导致任务栏跳动。我设法绕过了这个问题，但任务栏对图表大小调整的其他事件没有反应。最后，我决定保持原样。任务栏会在图表切换时跳转（只要存在返回错误值的问题），但在其他事件中会正常适应。

但这还不是全部。原来，调整图表大小的事件不会立即发生，而是会有半秒的延迟。这种延迟与重绘任务栏的时间叠加在一起，就会产生相当大的滞后。在这里，我无能为力。


我想说的是：当然，我已经大幅加速了图形处理，但代码中仍有一些其他未优化的解决方案。我正在努力解决这些问题。主要涉及窗口焦点转换和重绘队列。一些不必要的调用时有发生。任务栏滞后。我已经修复了我有时间修复的问题，尽管不是所有问题。剩下的就看接下来几天的了。否则，就没什么可改进的了......也许只能对代码进行梳理和熏香，使其芳香四溢））。

总的来说，如果我们调试好所有剩余的非优化解决方案，它就会飞起来...当然，是在 MQL 程序所能达到的速度范围内。


以发行版为例。

附加的文件：
KIB-DRIVE_v27.07.24.zip  1723 kb
 
Реter Konow #:

那么，最新情况......

...


让我这样说吧：当然，图形处理速度明显加快，但代码中仍有一些其他未优化的解决方案。我正在努力解决这些问题。主要涉及窗口焦点转换和重绘队列。一些不必要的调用时有发生。任务栏滞后。我已经解决了我有时间解决的问题，尽管不是所有问题。剩下的就看接下来几天的了。否则，就没什么可改进的了......也许只是梳理一下代码，给它加点香水，让它香喷喷的））。

总的来说，如果我们调试好所有剩余的未优化解决方案，它就会飞起来......当然，是在 MQL 程序所能达到的速度范围内。


以发行版为例。

让我明确一点：我们在这里讨论 的是速度。如果解决了焦点改变时窗口重绘的问题，界面速度将达到 MQL 程序的上限。任务栏的延迟可以部分解决。我想出了一个很好的解决方案--在任务栏的机械结构中应用动态窗口的原理--当调整大小或被框架拉动时，任务栏的速度不会减慢。它的调整速度会更快，也更不易察觉。当然，我们还需要取消不必要的重绘。这是必须的。但是，如果 CHARTEVENT_CHART_CHANGE 事件本身延迟到达程序，任务栏反应的明显滞后就不可避免，尽管这与它无关。

除此之外，界面开发和改进的方向还有很多。

 

再谈谈界面速度。

我花了很多时间检查延迟和寻找渲染刹车。负责 kanvas 布局的程序块是这样构建的：在初始化用于在 ResourceCreate() 函数中创建资源 的数组之前，它定义了窗口细节循环的边界。这需要借助为检查传入事件而配置的条件过滤器。调用程序块的每个事件都有绘制边界。例如，在元素对光标悬停的反应事件中，只对特定元素的详细信息启用循环边界过滤器。该图块在拍摄的图像上只选择其细节。在对细节进行循环时，它会在图像的其余部分中选择性地只绘制这些细节。它能准确地找到初始化的 位置，并绘制出正确元素的正确细节。同时，它还能正确地绕过图像空间的其他部分。

但加速效果不仅如此。如果画布上的点的颜色与所需值一致，程序块不会对其进行初始化。此外，它也不会在数组中 "运行"，而是 "跳转"，跳过一段距离。这样可以减少成百上千次的迭代周期。

不仅如此。由于图像数组是全局的（在全局级别声明），因此它的内存中始终存储着上一幅图像的变化。如果同一画布上继续发生变化，则会使用存储的图像，而不是每次都清空数组。如果资源名称在下一个事件中没有变化，则无需调用 ResourceReadImage()，也无需再次发送画布数组进行填充。该代码块无需调用 ResourceReadImage()，而是继续处理剩余数据，并在更改后使用 ResourceCreate() 更新图像。

这节省了大量调用ResourceReadImage() 的时间。同时也节省了清空和填充数组的时间。这是对全局内存的充分利用，不是吗？

重绘窗口时，根本不会调用该代码块。窗口组件会被擦除和创建，先前保存的资源会被附加到这些组件上。没有渲染。


尽管如此，仍会出现滞后现象，这是不可避免的。让我来解释一下这是怎么回事。

在首次打开窗口、首次打开标签页、打开树形列表或最小化/取消大空间建模时，都必须 重新绘制画布。在创建可在以后多次有效链接/更改的图像资源之前，您总是需要从头开始绘制一幅完整的图像。第一次绘制的时间总是最长的。没有什么可保存的，也没有保存的图像。第一次打开时总是会出现滞后现象。这是不可避免的。

不过，这里也有一个很好的解决方案：将打开窗口的延迟移到加载事件中。我的意思是：在加载构造函数的阶段，在后台绘制所有图像并提前保存到资源中，这样在打开时一切就都准备好了。这样，用户在首次打开窗口时就不会看到任何延迟。这当然很好，但也有缺点。首次打开时的延迟会变成加载时的延迟，加载时间也会增加。很难说会增加多少。我认为平均在一秒之内。这取决于具体的界面。

我认为这个方案更可取。我宁愿让设计器/用户界面的加载时间长一点，但这样就不会再有视觉上的打开延迟了。



我很想听听你们的意见。


已添加：

有一个想法是在第一次加载后将界面资源保存到文件中。这样后续加载就会更快，因为设计者/引擎已经掌握了必要的资源。需要考虑一下。

 
出问题了，彼得。
一秒钟的滞后是一个令人望而却步的滞后。整个窗口最复杂界面的形成不应超过 50 毫秒。
看起来渲染逻辑确实被更新函数（实际上是 ChartRedraw）超载了。
要验证这一假设，请在CCanvas 类（如果使用）的 Update 函数中加入一个静态计数器，并打印该计数器，例如当 count%100 == 0 时。
 

我也有一个全屏画布，每次更改都要完全重绘，但所需时间不超过 50 ms....

最昂贵的是绘制文本。因此，为了避免每次都使用 TextOut，我将它们存储在数组中。结果快多了。

1...464748495051525354555657585960...82
新评论