<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 29, 2016 at 3:48 AM, Paluszek, Lukasz <span dir="ltr"><<a href="mailto:lukasz.paluszek@airbus.com" target="_blank">lukasz.paluszek@airbus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">I tested the patch by simply replacing the two modified files and the new peeling worked with parallel rendering. </span></p></div></div></blockquote><div><br></div><div>Great!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">I noticed, however, that I cannot load any
 state files saved before the patch application (or even from previous versions), Paraview segfaulted each time. I did not investigate the matter any further but perhaps you could double check that there is no backward compatibility issue with older state files
 that do have opacity information. </span></p></div></div></blockquote><div><br></div><div>The changes only affected shader code in the rendering engine, this shouldn't make any difference in the ParaView state. Do they still segfault in master without patching the files for the opacity fix?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">In addition the peeling, regardless whether it’s the old or new implementation, takes significantly more time with parallel rendering than in the serial mode. Although, it’s expectable, the overhead is suspiciously high, I
 tried on 8 processes and a geometry which, in serial mode can be made opaque dynamically with no visible delay, took 34 seconds to be rendered. Most of the overhead comes from parallel distribution for compositing.</span></p></div></div></blockquote><div><br></div><div>Was it 34 seconds for the initial frame, or for every frame? If the dataset is large a longer first render would be expected as the data propagates.</div><div><br></div><div>Dave</div></div></div></div>