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

新评论
 

不幸的是，今天通过用 "数字掩码 "保存阵列来应对图像更新延迟的问题的尝试并不成功。然而，它也不是一个失败。根本不可能对延误的原因得出明确的结论，也不可能找到解决问题的全面办法。

在思考将完成的图像存储在内存中并处理其区域的一般方法时，我经历了各种选择。那些我认为是好的解决方案，经过深思熟虑后发现是不切实际的。

因此--我的结论。

1.如果你想在数组中保存图像，应该有很多数组。也就是说，每个资源都需要自己的恒定内存阵列。在我的实现中，画布（资源，canvases）的数量可能比窗口的数量多几倍。

我将解释原因。

在某些情况下，这种方法比在一个画布上绘制所有的窗口对象要方便得多，例如，当在 "视场（VEIW BOX）"元素中滚动一个表格时，将表格元素放在这个元素内部的一个单独的画布上，并将这个画布作为一个整体对象滚动，就很方便。所以，每个这样的元素都在其中携带了一个单独的卡布。否则，它将不得不覆盖保存在内存中的整个窗口图像。这肯定会让你花更多时间。

此外，在一个画布上画所有的窗口是很不方便的，那么如何移动它们呢？假设我们为整个图表区域创建一个 "巨型 "画布。我们所有的窗户都将被画在上面。在画完画布上的窗口后，我们将尝试移动它们，但要做到这一点，我们将不得不重写这个单一的 "巨型 "画布的整个画面。图片非常大，重写的数值也会非常大。即使图片被保存下来，我们也必须在每次光标移动时覆盖内存中的巨大区域。很明显，这是不高效的。

2.在思考保存图片和处理图片的方法时，我想起了 "ResourceReadImage() "函数。该函数读取资源并将其数字掩码放入一个数组。所以，--不需要保存图像，因为它已经保存在终端级别，可以用这个函数调用。这大大简化了任务。所以：你可以用 "ResourceReadImage() "获取图片，将其放入一个数组，然后改变数组的值，与接口的 "事件下 "的特定元素有关。在我看来，这种方法看起来更有吸引力。然而，问题仍然存在--使用 "ResourceReadImage() "将图像填充 到数组 中需要多长时间？很明显，这也取决于画布的面积。它可能在视觉上根本不明显，但无论如何，当光标位于某个特定的画布区域时，它应该只被加载一次。当移动到另一个kanvas时，你可以清除阵列并上传另一个kanvas的图像。

总之，我现在没有一个最终的解决方案。我必须尝试使用 "ResourceReadImage() "函数，测量图像加载时间，并开发处理数组中图像区域的系统。

暂时就这些了。
 

Реter Konow:

在我实现的界面中，画布（资源，canvases）的数量可以比窗口的数量多几倍。 这是实践的需要。

你的实践需要它。

但正如你自己的实践所表明的那样--这种实施在速度和便利性方面是有缺陷的。

实践证明，用一个画布工作更方便，在你的画布上临时画表窗口，然后在主画布上使用BitBlt，没有任何障碍。

我不知道你为什么计划 "必须有很多数组。"但你自己看到，这是一条死路。

 
o_O:

这是你的实践所需要的。

但正如你自己的实践所表明的那样--这样的实施在速度和便利性方面是有缺陷的。

实践证明，用一个画布工作更方便，在你的画布上临时画表窗口，然后在主画布上使用BitBlt，没有任何障碍。

我不知道你为什么计划 "必须有许多数组，而且是无限多的数组......"。"但你自己看到，这是一条死路。

也许你已经找到了一个更好的解决方案。我很想看到它。如果可以的话，请发布一个GIF，你可以清楚地看到元素对点击的反应有多快。之后我再把我的GIF贴出来。你会看到我在说什么，我也会看到你在说什么。
 
Реter Konow:
也许你已经找到了一个更好的解决方案。我很想看到它。如果可以的话，请贴出一张GIF，你可以清楚地看到点击时项目的响应速度。之后我再把我的GIF贴出来。你会看到我在说什么，我也会看到你在说什么。

我没有录制视频，但我给你发了一个例子。 这是一个快速草图。

有600个下拉列表。

移动鼠标--随着每个事件和颜色的变化，整个CCanvas被重新绘制。

你可以在位图属性中看到最终的尺寸--1500x600 px（与你的800x500和250ms滞后相比）。这相当于900,000个像素，而且都是即时重绘。 没有几秒钟是不可能的。

每个列表首先在自己的画布上以自己的尺寸呈现（为了不溢出），然后在整体上进行耕耘。因此，我们在每个鼠标事件中有600个ResourceCreate调用。
这意味着，正如你从反应速度中看到的那样，帧数足以显示动画片。

MT开发者提供了令人满意的工具，没有滞后性（我指的是ResourceCreate bitmaps）。

附加的文件：
Gtest.ex5  150 kb
 
o_O:

我没有录下视频，但我把一个例子发给你。

有600个下拉列表。

移动鼠标--随着每个事件和颜色的改变，整个CCanvas被重新绘制。

你可以在位图属性中看到最终的尺寸--1500x600 px（与你的800x500和250ms滞后相比）。这相当于900,000个像素，而且都是即时重绘。 没有几秒钟是不可能的。

每个列表首先在自己的画布上以自己的尺寸呈现（为了不溢出），然后在整体上进行耕耘。因此，我们在每个鼠标事件中有600个ResourceCreate调用。
这意味着，正如你从反应速度中看到的那样，帧数足以显示动画片。

MT开发者提供了令人满意的工具，没有滞后性（我指的是ResourceCreate bitmaps）。

嗯，这足以证实你的话......然而，我重复我昨天的问题：图像是否保存？

我昨天说过--如果你存储一次创建的图像，只改变其中的特定区域，并立即发送至ResourceCreate()，就不会有延迟。你在画布上的工作方法我还不熟悉。我还不知道你是如何取得这一成果的。

我还有一个问题：用CCanvas类来创建上述例子，你能描述一下这个方案的实现原理吗？

也许那里使用了位操作来处理图像。我还没有和他们打过交道。


P.S. 然而，我喜欢自己解决秘密...)无论如何，我将解决这个问题。

 
Реter Konow:
使用CCanvas类来创建上述例子，你能描述一下这个解决方案的实现原理吗？

原理是线性的--穿过控件列表，在画布上的规定位置绘制每一个控件。
只有CCanvas函数被用于绘制控件。我没有做任何自己的事情。

例如，在折叠的表格中，那些列表被画成两个元素--在这个例子中，是按钮（这在其他样式中是不同的）。
帆布函数被称为
FillRectangle // 填充背景
矩形//周围的框架
FontSet // 设置字体
TextOut // 输出文本

那里有可能使用了位操作来处理图像。

不。

图像是否保存？

是的，在CCanvas中的阵列中。

如果你一旦创建了一个图像，只改变其中的一个特定区域，并立即将其发送到ResourceCreate()，就不会有延迟。

不太对。

在我的例子中，整个数组被重新绘制。每次重绘时，数组被清空，整个画布被再次填充。然后调用ResourceCreate。

 
o_O:

在我的例子中，整个数组被重新绘制。每次重绘时，数组被清空，整个画布被再次填充。然后调用ResourceCreate。

谢谢你的详细回答。

奇怪的是，对我来说也是如此。在每个界面事件中，整个窗口的图像被完全重新创建。它被建立在一个本地的一维数组中，在这个程序完成后，它被发送到ResourceCreate。

我不知道为什么它拖累了我......明天我将发布一个GIF，在那里我将展示窗口大小和项目响应速度之间的相关性。

这一切都非常奇怪...

 
Реter Konow:

谢谢你的详细答复。

奇怪的是，对我来说也是如此。在每个界面事件中，整个窗口的图像被完全重新创建。它被建立在一个本地的一维数组中，在这个程序完成后，它被发送到ResourceCreate。

我不知道为什么它拖累了我......明天我将发布一个GIF，在那里我将展示窗口大小和项目响应速度之间的相关性。

这一切都非常奇怪...

如果你不介意，在任务管理器中用CPU负载做一个gif动画。或者像sergeev 那样更容易发布一个编译的文件。所以你可以自己测试一下。
 
Anatoli Kazharski:
如果不难，在任务管理器中用CPU负载做一个gif动画。或者像sergeev 那样，把编译后的文件贴出来 更容易。所以人们可以自己测试。

好吧，我做一个CPU负载的视频。但是，关于编译的文件--我还不会公布它。

只是很惭愧的虫子......）））)

当我修好它们时，我保证将它们张贴出来。

 
Реter Konow:

好吧，我做一个CPU负载的视频。但关于编译的文件--我还不会公布。

只是很惭愧的虫子......）））)

当我修好它们时--我保证会发布。

好的。慢慢来。)
1...111213141516171819202122232425...45
新评论