在 Java SWT 中将绘图线程化到画布上
一段时间以来，我一直在做一些我只能描述为“线程画布”的事情。稍后我将描述我所拥有的内容，但由于我确实乐于接受新想法、现有解决方案或全新的开始，所以我将阐述问题。
画布的目的是显示遗传信息（尽管具体目的有些无关）。作为传统的文本编辑器，该遗传代码被绘制到画布上，用户可以在画布上通过键入、选择等方式与其进行交互。然后，该代码进一步用各种非文本特征（例如形状、线条和颜色）进行装饰。
这里的主要问题是在显示某些信息之前需要进行大量计算。
考虑以下模型：
画布示例 http://img23.imageshack.us/ img23/9931/canvasgv.png
如您所见，遗传密码是等宽的，但酶切（显示在遗传密码上方）不是等宽的。计算酶切割的位置是乏味的，因为屏幕上可能有很多特征（上面的蓝色箭头）。三字母代码表示三个遗传密码块的翻译；尽管执行速度很快，但在序列中输入一个字母会使它们全部移动一个——需要重新计算。
最好，为了加快速度，这些部分中的每一个都可以出现在一个单独的线程中，最终组合在一起组成最终的图像。
总结：显示的各个部分在计算上是困难的，尽管当然希望编辑器尽可能地响应。
我目前的实现涉及在各个线程中执行所有绘制事件。通过键入、调整大小或进行选择，可能会创建大量线程，但只有最新的线程才会继续更新显示。这保证了更新显示的时间不会超过一次迭代，但不会提供 UI 的快速反馈。
我研究过对现有编辑器进行修改，例如 StyledText，但除了一些粗体和颜色之外的任何内容都会使其速度明显变慢。
有什么建议吗？
I've been working quite a bit on something I can only describe as a "threaded canvas" for some time now. In a moment I'll describe what I have, but since I'm really open to new ideas, existing solutions or a completely fresh start, I'll formulate the problem.
The canvas is intended to display genetic information (although the specific purpose is somewhat irrelevant). As a conventional text editor, this genetic code is drawn to a canvas, upon which the user can interact with it by typing, selecting, etc. The code is then further decorated with various non-text features such as shapes, lines and colors.
The primary issue here is that significant calculations need to be made prior to displaying certain information.
Consider the following mock-up:
Sample of canvas http://img23.imageshack.us/img23/9931/canvasgv.png
As you can see, the genetic code is monospaced, but the enzyme cuts (shown above the genetic code) are not. Computing where enzymes cut is tedious, as can be displaying features (above, the blue arrow) as there may be very many on-screen. The three-letter codes indicate translations of three blocks of genetic code; although this is performed quickly, typing a single letter into the sequence makes them all shift by one--requiring a recalculation.
Preferably, to speed things up, each of these parts could occur in a separate thread, coming together in the end to compose the final image.
Summarizing: individual parts of the display are computationally difficult, though it is of course desirable that the editor is as responsive as possible.
My present implementation involves performing all draw events in individual threads. By typing, resizing or making selections, a large number of threads may be created, but only the most recent one proceeds to update the display. This guarantees that updating the display takes no longer than one iteration, but doesn't provide snappy feedback of the UI.
I've looked into making modifications to existing editors such as StyledText, but anything more than some boldface and colors makes it significantly slow.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
也许您最好的选择是在 StyledText 中嵌入其他 SWT 小部件。每个小部件都将在后台线程中执行特定计算，并在结果出现时更新其视觉表示。请注意，您可以在后台执行计算，但渲染必须在 SWT 线程中进行。所以在渲染的时候你不能做很多复杂的事情。如果速度变得太慢，请使用缓存图像（创建几个屏幕外图像，您可以在其中渲染结果，然后简单地绘制这些图像）。
从
Canvas因为这是用于自定义渲染的小部件。它还允许您对不同的事件做出反应（即，当用户将鼠标悬停在酶切上时显示附加信息）。不过，要小心酶切：它们的高度各不相同。我建议默认情况下给这个小部件多一点空间（即使不使用它），这样在小部件计算和添加剪切时文本就不会跳太多。
Probably your best bet is to embed other SWT widgets in the StyledText. Each widget will perform a certain calculation in a background thread and update its visual representation as the results come in. Note that you can do the calculations in the background but the rendering must happen in the SWT thread. So you can't do many complex things during rendering. If things become too slow, use cache images (create a couple of off-screen images where you can render the results and then simply draw those images).
Extend these widgets from
Canvasas this is the widget intended for custom rendering. It will also allow you to react to different events (i.e. display additional information when the user hovers over an enzyme cut).Be careful with the enzyme cuts, though: They vary in height. I suggest to give this widget a bit more space by default (even when it's not used) so the text doesn't jump a lot while the widget calculates and adds cuts.
相反，我选择了使用多个缓冲区的解决方案，其中每个缓冲区都在单独的线程中绘制。性能比 StyledText 好得多，而且我可以完全灵活地在我喜欢的地方绘制东西。
唯一的缺点是我必须重新实现文本编辑的基础知识：文本选择、导航——甚至是输入字符的基础知识。尽管如此，我对结果还是很满意的。
恐怕我无法提供源代码，因为它是受版权保护的项目的一部分。
I instead chose for a solution using multiple buffers, where each buffer is drawn in a separate thread. The performance is much better than StyledText, and I have complete flexibility to drawing things where I like.
The only drawback is that I have to reimplement the basics of text editing: text selection, navigation -- even to the basics of entering characters. I am nevertheless satisfied with the result.
I'm afraid I cannot provide source code as it is part of a copyrighted project.