加速 GTK 树视图
我正在使用 pygtk 为 Maemo 平台编写一个应用程序，树视图的渲染速度似乎是一个问题。 由于该应用程序是一个媒体控制器，我在 UI 中使用过渡动画。 当在 UI 中移动时，这些动画会将控件滑入视图。 树控件的问题是速度慢。
仅在屏幕中间移动小部件并不算慢，但如果单元格暴露，帧速率确实会下降。 更烦人的是，如果唯一暴露的区域是带有行标签的标题行，则帧速率仍处于控制之下。
据此判断，我怀疑 GTK 树视图在每次暴露单行像素时都会再次绘制完整的单元格。 有没有办法以某种方式强制 GTK 将整个小部件绘制到某个缓冲区中，即使它的一部分不在屏幕上，然后在动画时使用缓冲区来绘制小部件？
使用视口向上滚动和使用布局面板向下移动小部件之间是否有区别？ 我本以为 Viewport 更快，但当我尝试这两个版本时，我发现没有真正的区别。
我知道这不一定是 GTK 的创建目的。 我尝试过的其他替代方案是 pygame，但我更喜欢一些更高级别的实现，内置基于小部件的事件处理。此外 pygtk 具有在 Windows 和窗口中运行的优点，因此开发更容易。
I'm writing an application for the Maemo platform using pygtk and the rendering speed of the tree view seems to be a problem. Since the application is a media controller I'm using transition animations in the UI. These animations slide the controls into view when moving around the UI. The issue with the tree control is that it is slow.
Just moving the widget around in the middle of the screen is not that slow but if the cells are being exposed the framerate really drops. What makes this more annoying is that if the only area that is being exposed is the title row with the row labels, the framerate remains under control.
Judging by this I'm suspecting the GTK tree view is drawing the full cells again each time a single row of pixels is being exposed. Is there a way to somehow force GTK to draw the whole widget into some buffer even if parts of it are off screen and then use the buffer to draw the widget when animating?
Also is there a difference between using Viewport and scrolling that up and using Layout panel and moving the widgets down? I'd have imagined Viewport is faster but I saw no real difference when I tried both versions.
I understand this isn't necessarily what GTK has been created for. Other alternative I've tried is pygame but I'd prefer some higher level implementaion that has widget based event handling built in. Also pygtk has the benefit of running in Windows and a window so development is easier.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我自己从未这样做过，但您可以尝试自己实现缓存。 不要使用预定义的单元格渲染器，而是实现您自己的单元格渲染器（可能作为实际单元格渲染器的包装器），但缓存像素图。
在 PyGTK 中，您可以使用
gtk.GenericCellRenderer。 在装饰器单元渲染器中，当要求渲染时执行以下操作：最后一步也意味着缓存确实会产生第一次渲染单元格期间的开销。 通过使用缓存策略可以稍微缓解这个问题。 您可能想要根据渲染值的分布尝试不同的事情：
话虽这么说，我不能说这是否会产生任何影响。 我从一个有点类似的问题中获得的经验是，任何涉及文本的内容通常都足够慢，因此缓存是有意义的——抱歉，我无法提供更简单的建议。
在尝试之前，您还可以简单地编写一个装饰单元格渲染器，它只计算单元格实际渲染的频率并获取一些计时信息，以便您了解热点在哪里以及缓存这些值是否有意义根本不。
I never did this myself but you could try to implement the caching yourself. Instead of using the predefined cell renderers, implement your own cell renderer (possibly as a wrapper for the actual one), but cache the pixmaps.
In PyGTK, you can use
gtk.GenericCellRenderer. In your decorator cell renderer, do the following when asked to render:The last step also implies that caching does incur an overhead during the first time the cell is renderered. This problem can be mitigated a bit by using a caching strategy. You might want to try out different things, based on the distribution of rendered values:
That being said, I can't say if it's going to make any difference. My experience from a somewhat similar problem is that anything involving text is usually slow enough that caching makes sense---sorry that I can't give simpler advice.
Before you try that, you could also simple write a decorating cell renderer which just counts how often your cells are actually rendered and get some timing information, so that you get an idea where the hot spots are and if caching the values would make any sense at all.