<div>Hi Berk,</div><div><br></div><div>I've put a patch on gerrit that merges update extents, i.e. for when one output has multiple consumers and each consumer needs a different update extent. This is specific to structured data. Could you take a look?</div>
<div><br></div><div><a href="http://review.source.kitware.com/446">http://review.source.kitware.com/446</a></div><div><a href="http://www.vtk.org/Bug/view.php?id=11515">http://www.vtk.org/Bug/view.php?id=11515</a></div><div>
<br></div><div>Thanks in advance,</div><div><br></div><div> David</div><div><br><br><div class="gmail_quote">On Wed, Nov 24, 2010 at 3:39 PM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com">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;">Hi All,<div><br></div><div>I've been looking at the vtkStreamingDemandDrivenPipeline and have been a bit surprised about the way UPDATE_EXTENT requests are handled. Whenever an AlgorithmOutput gets UPDATE_EXTENT requests from more than one downstream object, a segfault can occur unless all downstream objects request exactly the same extent. Here is a simple tcl example to demonstrate this:</div>
<div><br></div><div>=========</div><div><div>package require vtk</div><div><br></div><div># Simple examle that crashes when an UpdateExtent request</div><div># from one algorithm is overwritten by a smaller UpdateExtent</div>
<div># request from another algorithm</div><div><br></div><div># read an image that has an extent of 0 255 0 255 0 0</div><div>vtkPNGReader reader</div><div>reader SetDataSpacing 0.8 0.8 1.5</div><div>reader SetFileName "$VTK_DATA_ROOT/Data/fullhead15.png"</div>
<div><br></div><div># Uncomment this to make the crash disappear</div><div>#reader Update</div><div><br></div><div># clip the image down to 0 127 0 127 0 0</div><div>vtkImageClip clip</div><div>clip SetInputConnection [reader GetOutputPort]</div>
<div>clip SetOutputWholeExtent 0 127 0 127 0 0</div><div><br></div><div># do an operation on the clipped and unclipped data</div><div>vtkImageBlend blend</div><div>blend SetInputConnection [reader GetOutputPort]</div><div>
blend AddInputConnection [clip GetOutputPort]</div><div><br></div><div>vtkImageViewer viewer</div><div>viewer SetInputConnection [blend GetOutputPort]</div><div>viewer SetColorWindow 2000</div><div>viewer SetColorLevel 1000</div>
<div>viewer Render</div><div>==========</div></div><div><br></div><div>Running this example gives this error, followed by a segfault:</div><div><div><br></div><div>ERROR: In /Volumes/Work/Kitware/vtk-git/Filtering/vtkImageData.cxx, line 1472</div>
<div>vtkImageData (0x10630fe10): GetScalarPointer: Pixel (0, 128, 0) not in memory.</div><div> Current extent= (0, 127, 0, 127, 0, 0)</div></div><div><br></div><div>The reason for the segfault is that the reader is given two UPDATE_EXTENT requests:</div>
<div>First, the vtkImageBlend requests an extent of 0 255 0 255 0 0.</div><div>Second, the vtkImageClip requests an extent of 0 128 0 128 0 0.</div><div><br></div><div>The StreamingDemandDriven pipeline does not combine these requests, it just sets the data extent according to the last UPDATE_EXTENT request. So, the vtkImageBlend only gets half of the data that it expects on its first input. The pipeline should be more robust than that. With a properly implemented pipeline, the tcl example that I ave above should not segfault.</div>
<div><br></div><div>There is no easy fix. Each AlgorithmOutput has only one UPDATE_EXTENT slot, and the imaging filters (and the sddp) set that slot directly, without first checking to see if it has already been set by some other downstream object. One fix would be to add a method to the SDDP that combines the update extents, and then modify the image filters so that they use that method instead of setting UPDATE_EXTENT directly. Like I said, not an easy fix.</div>
<div><br></div><div>Has anyone else run into this problem? Does this also afflict streaming in the graphics pipeline?</div><div><br></div><font color="#888888"><div> David</div><div><br></div>
</font></blockquote></div><br></div>