<div dir="ltr">On Wed, Mar 20, 2013 at 7:12 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> A backward compatible approach might use an additional offset array into the existing cell ids array.<br></blockquote>

<div><br></div><div style>Backwards compatibility is definitely the biggest obstacle to a change like this. This approach would lose some of the nice features we've discussed like super-fast VBO creation, but would be a step in the direction of allowing a cellId-based random-access API, which is more important for my needs at the moment. However, the memory overhead of duplicating the cell size information may be unacceptable in some cases.</div>

<div style><br></div><div style>The other approach Berk proposed is to introduce an abstract class above vtkCellArray that only uses sequential access via GetNextCell, etc, and rewrite only selected filters to use this API, since coprocessing adapters should be able to handle sequential access without much trouble. (As I mentioned earlier in my reply to Will, The real thorn in my side for this project is the array-index random access methods). This would certainly be easier, and leave a major rewrite/redesign for a later project, perhaps one that has the resources to update VTK away from the fixed-pipeline GL approach.</div>

<div style><br></div><div style>Dave</div></div></div></div>