<div dir="ltr">++1 = 2<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-24 17:42 GMT+01:00 Will Schroeder <span dir="ltr"><<a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 12:11 PM, David Lonie <span dir="ltr"><<a href="mailto:david.lonie@kitware.com" target="_blank">david.lonie@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Anyone else want to share an opinion?</blockquote></div><br></span>Polishing the API and code is a good thing, and we've seen a lot of organic growth and improvement over the 22+ years VTK has been in existence. Done thoughtfully with minimal disruption I am fine with it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Having said that, I think there is sometimes a tendency to get caught up in too much polishing and software process and forget core algorithmic and performance concerns. There are so many algorithms and emerging computing technologies that we need to integrate and/or add into VTK. For me APIs are a secondary concern to capability. For example, I think that STL's API absolutely sucks but I use it because the implementation is often quite good, and it provides capabilities that benefit me, so I put up with the API. Another example is the recent OpenGL2 work: we could have revamped the API/design since there are arguable deficiencies in the lights/cameras/actors model, but Ken & Team made the hard to decision to mostly preserve the API warts and all and rework the inner workings seeing 10-100x performance gains with little impact on current applications except that they are a lot faster. That makes customers really happy. Changing API makes them really mad. Before we were constantly getting complaints about rendering speed, rarely about API, and now those rendering complaints seem to be mostly gone.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Long term VTK will thrive because it's up to snuff in terms of current algorithms and computing capabilities. A perfect API will not prevent it's death. Surely it's a balance, I get that, but IMO I'd like to see more cycles go into algorithms, computing, and performance.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Best,<br>W<span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div>William J. Schroeder, PhD<br>Kitware, Inc. - Building the World's Technical Computing Software<br>28 Corporate Drive<br>Clifton Park, NY 12065<br><a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a><br><a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a><br>(518) 881-4902</div></div></div>
</font></span></div></div>
<br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
<br></blockquote></div><br></div>