Re: [K3d-development] Painter Cache [was:] Generic Polyhedron Primitives
Brought to you by:
barche
From: Bart J. <bar...@li...> - 2009-05-18 19:21:07
|
On Mon, May 18, 2009 at 8:37 AM, Timothy M. Shead <ts...@k-...> wrote: > We're still glossing-over some details here ... such as cached data that > is derived from multiple sources. A cached triangulation for example, > needs to change whenever one of several arrays in a mesh / polyhedron > change. Ideally, the key should be based on each of those arrays, so > this is an area for experimentation. Well, as far as cache update is concerned, this is not really an issue: the hint will be passed along, and if the hint indicates that there is reason to recalculate, it will be done, regardless of the key type. For triangle data we could use the face_first_loops array, for example. On the other hand, getting the correct data is more critical. If the face_first_loops array happens to be shared across meshes, problems will occur. Maybe in the case of multi-array painters using the pointer to the primitive itself would be the best choice. That means the key type would have to remain templated, although I have a feeling there should be a simpler way. >>>> All the removal systems would be greatly simplified if we simply >>>> removed all data that wasn't used in the last scene redraw. This would >>>> be some sort of LRU I guess. Not sure if we can currently be notified >>>> of redraw begin and end, but I assume there is no objection to >>>> creating signals for that? >>> Arguably we shouldn't even need to do that. If there is a threshold on >>> cache size, you need only remove old items from the cache when adding a >>> new item causes the cache to cross that threshold. There are two >>> strategies here: how the threshold is defined, and how to choose what >>> gets removed. There's plenty of room for interested research there, so >>> they should be generic / separate from the cache itself, which should >>> merely handle the details of key-value lookup and storage. >> >> I've updated the wiki page with two alternatives. I prefer the "check >> every redraw" method, since it will be closer to the optimal case than >> fixing a cache size. The disadvantage is that we would need a new >> "on_redraw" signal. > > Sounds good, I would nuance this in a couple of ways: OK, I think the best way forward is to start with the stack-based LRU algorithm. This seems the simplest to implement, and we can always optimize when we feel the need. Cheers, -- Bart |