<div dir="ltr">I marked it as fixed because I was told it was and because the dashboard stopped showing the issue at about the right time.<div><br></div><div><div>Won't fix or Open are fine by me and I lean toward open. In any case Fixed is definitely not right! My fault sorry about that.</div>

</div></div><div class="gmail_extra"><br clear="all"><div>David E DeMarle<br>Kitware, Inc.<br>R&D Engineer<br>21 Corporate Drive<br>Clifton Park, NY 12065-8662<br>Phone: 518-881-4909</div>
<br><br><div class="gmail_quote">On Fri, Jan 17, 2014 at 2:24 PM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I understand.  However, if the bug isn't fixed and there is a very low<br>
probability that it every will be fixed, it should be marked as "won't fix"<br>
instead of being marked as "fixed".<br>
<br>
So I'm just wondering how it came to pass that the bug is marked as<br>
fixed, when it isn't.<br>
<span class="HOEnZb"><font color="#888888"><br>
  David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Jan 17, 2014 at 12:11 PM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>> wrote:<br>
> I'm pretty sure that did not fix the bug.<br>
><br>
> We spent a lot of time on this one. The volume rendering code is old<br>
> and tough to follow.<br>
><br>
><br>
><br>
> On Fri, Jan 17, 2014 at 1:38 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
>> I went back to the bug report on this multi-threading issue, and oddly<br>
>> enough the bug is marked as "fixed":<br>
>> <a href="http://www.vtk.org/Bug/view.php?id=13420" target="_blank">http://www.vtk.org/Bug/view.php?id=13420</a><br>
>><br>
>> A note in the bug report says "Was fixed in commit: e4a793c47cc3"<br>
>> But I looked at the commit, and it seems to be unrelated.  Why was<br>
>> the bug closed, when the problem still exists?  Was it closed<br>
>> accidentally?<br>
>><br>
>>   David<br>
>><br>
>><br>
>> On Fri, Jan 17, 2014 at 10:40 AM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
>>> On Fri, Jan 17, 2014 at 10:07 AM, David Cole <<a href="mailto:dlrdave@aol.com">dlrdave@aol.com</a>> wrote:<br>
>>>><br>
>>>> If that warning is true, then shouldn't any test that uses that class set<br>
>>>> the number of threads to 1 instead of trying to use all the cores available<br>
>>>> on a machine......?<br>
>>><br>
>>> Bill already fixed a bunch of tests to set NumberOfThreads=1 for this<br>
>>> mapper.  TestSmartVolumeMapperWindowLevel must have slipped through<br>
>>> the cracks.<br>
>>><br>
>>>> Does anybody really want non-repeatable results?<br>
>>><br>
>>> Fixing the bug in the mapper would be the correct way of ensuring<br>
>>> repeatable results: it's a multi-threaded mapper, but running it<br>
>>> with too many threads causes artifacts.  In my view, the<br>
>>> "SetNumberOfThreads(1)" trick is a way of sweeping the problem<br>
>>> under the rug, out of sight and out of mind.<br>
>>><br>
>>>   David<br>
</div></div></blockquote></div><br></div>