Re: [K3d-development] Painter Cache [was:] Generic Polyhedron Primitives
Brought to you by:
barche
From: Bart J. <bar...@li...> - 2009-05-16 22:46:00
|
On Fri, May 15, 2009 at 5:47 AM, Timothy M. Shead <ts...@k-...> wrote: > * Although it's great to put Node Visibility, Per-Render-Engine > Painters, and the Painter Cache in context, they should all represent > orthogonal functionality. If any one of these depends on the others, > we're doing something fundamentally wrong. Agreed! However, I think there are no dependencies in the current proposal. In fact, using k3d::imesh_source as type used in the painter methods eliminates a dependency that exists today, namely that mesh_instance must keep its output mesh pointer constant for the sake of painter caches. I merely put them all on the page to illustrate their role in the visualization pipeline. I have removed the archive section, since most important points are repeated in the new version, and the rest was obsolete. > * I want to approach the cache with more open eyes - in particular, I > think the current cache is far too complex, and I want to look at > simplified approaches such as LRU or Multi Queue: OK, I think the on-demand creation of the cached data is OK as it is. Timely removal , on the other hand, is flawed and causes complexity. Currently, data is only removed when either the mesh is deleted or when the last painter using the cached data is deleted. There is no check to see if a connection between a mesh and a painter changed and caused data to become useless (tracking this would be a nightmare). 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? Cheers, -- Bart |