我从来没有这样做,但你可以尝试实现缓存自己。不要使用预定义的单元呈现器,而是实现自己的单元呈现器(可能作为实际的单元呈现器的包装器),但是缓存pixmap。
在PyGTK,你可以使用
gtk.GenericCellRenderer
. 在decorator单元格呈现程序中,在要求呈现时执行以下操作:
-
保存一个屏幕外像素的缓存(或者更好,只有一个大像素)和一个大小的缓存
-
如果要求预测大小或渲染,请从相关属性创建键
-
如果密钥存在于缓存中,请使用缓存的pixmap,将缓存的pixmap放到给定的drawable上。
-
否则,首先让实际的单元渲染器完成工作,然后复制它
最后一步还意味着缓存在第一次呈现单元格时确实会产生开销。这个问题可以通过使用缓存策略来减轻。根据渲染值的分布,您可能需要尝试不同的方法:
-
如果所有的单元都是唯一的,那么除了将所有内容缓存到某个限制或某个mru策略之外,就没什么可做的了。
-
如果你有某种
Zipf distribution
,也就是说,有些单元格非常常见,而另一些单元格则非常罕见,您应该只高速缓存这些单元格,而不必为很少的单元格值花费缓存开销。
话虽如此,我不能说这会不会有什么不同。我从一个类似的问题中得到的经验是,涉及文本的任何事情通常都很慢,以至于缓存是有意义的,抱歉我不能给出更简单的建议。
在尝试之前,您还可以简单地编写一个装饰单元呈现器,它只计算实际呈现单元的频率,并获取一些计时信息,以便您了解热点在哪里,以及缓存这些值是否有任何意义。