<br><br><div><span class="gmail_quote">On 1/2/07, <b class="gmail_sendername">Berk Geveci</b> <<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I haven't looked at/used mangled mesa in a while. I used to enable it<br>on all my builds for testing but eventually gave it up. As Brian<br>mentioned, having a separate mesa build is more practical. There are<br>two maintenance issues with mangled mesa: 1. mangling support in the
<br>mesa library itself, 2. mangled mesa support in VTK. (2) is not too<br>much of a burden although as Randall found out, it is not being tested<br>(therefore it may be considered broken). (1) is more of a problem<br>since Mesa folks are not really interested in it and do not test
<br>mangled mesa. The last time I tried, the latest mesa could not be<br>built mangled. I think there are some users of mangled mesa out there<br>but I am not sure how many. Jeff Lee may be one of them.</blockquote><div><br>
Hi All,<br>Yes, we are using it to do offscreen rendering in an interactive client.  The nice thing is that the same version of our rendering libraries work both in batch and interactive, but the same thing could be accomplished by having 2 builds of the rendering libs, as Berk said above (it would be nice if cmake produced the 2 different versions, instead of having completely separate builds).  In batch, osmesa seems to be the only real choice for rendering without an xserver, but interactive we can use glxpixmap, pbuffer, or fbo, so no real need to do mangled mesa when interactive to get higher resolution hardcopy.
<br><br>On another note, for what we're trying to do (and probably most people), it would be much more convenient to have an offscreen context in the renderwindow that we can just make current and use, instead of the SetOffscreenRendering() call.  The two scenarios I commonly see are you are either always rendering offscreen, or you are making a high-res hardcopy and don't want the current context to be messed with, but you don't really need to go through all that SetOffscreenRendering() does to accomplish that.  Lets say you were creating an animation and wanted to save the animation as a higher resolution than the onscreen context - basically every frame you have to call SetOffscreenRendering to get your offscreen context to render to, and then you have to throw it away when you update the onscreen context - why not just add the ability for a vtkRenderWindow to have an additional (or many) context(s) to render into.
<br>-J<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-berk<br><br>On 1/2/07, Moreland, Kenneth <<a href="mailto:kmorel@sandia.gov">
kmorel@sandia.gov</a>> wrote:<br>><br>><br>><br>> I'm pretty sure the current use of this feature at Sandia is zero.  All of<br>> our distributions of ParaView use either a hardware driver or straight Mesa,
<br>> not both.  As several other members of these lists have just testified, it's<br>> much easier.<br>><br>> Concerning the maintenance overhead of maintaining the mangled Mesa stuff, I<br>> would rather have someone from Kitware speak to that since they are really
<br>> the ones doing that.  I recall Berk grumbling about it in the past.  Perhaps<br>> he can elaborate.<br>><br>> I also cannot speak for any other organizations that may be using<br>> VTK/ParaView.  If any of you out there use the vtkMesa* classes or otherwise
<br>> compile with the mangled Mesa features, now would be a really good time to<br>> chime in.<br>><br>> -Ken<br>><br>>  ________________________________<br>>  From: paraview-bounces+kmorel=<a href="mailto:sandia.gov@paraview.org">
sandia.gov@paraview.org</a> on behalf of James P.<br>> Ahrens<br>> Sent: Sat 12/30/2006 4:35 PM<br>> To: <a href="mailto:paraview@paraview.org">paraview@paraview.org</a><br>> Cc: <a href="mailto:ahrens@lanl.gov">
ahrens@lanl.gov</a><br>> Subject: [Paraview] Re: ParaView Digest, Vol 32, Issue 23<br>><br>><br>><br>><br>> > Message: 1<br>> > Date: Fri, 29 Dec 2006 09:05:35 -0600<br>> > From: "Randall Hand" <
<a href="mailto:randall.hand@gmail.com">randall.hand@gmail.com</a>><br>> > Subject: Re: [Paraview] RE: [vtkusers] MangledMesa & VTK<br>> > To: "Sean Ziegeler" <<a href="mailto:seanzig@users.sourceforge.net">
seanzig@users.sourceforge.net</a>><br>> > Cc: <a href="mailto:paraview-developers@public.kitware.com">paraview-developers@public.kitware.com</a>, VTK Users<br>> >       <<a href="mailto:vtkusers@vtk.org">
vtkusers@vtk.org</a>>,     <a href="mailto:paraview@paraview.org">paraview@paraview.org</a><br>> > Message-ID:<br>> ><br>> <<a href="mailto:b02264720612290705h54bc20a6yf45d6b335f1f644e@mail.gmail.com">
b02264720612290705h54bc20a6yf45d6b335f1f644e@mail.gmail.com</a>><br>> > Content-Type: text/plain; charset="iso-8859-1"<br>> > ><br>> > So maybe mangling isn't really necessary anymore, except for those times
<br>> > where you need to switch between Hardware OpengL & Mesa on the fly..<br>> > Anyone<br>> > actually doing that tho?<br>> ><br>><br>> The original purpose of the mangled mesa extension was a heterogeneous
<br>> configuration with hardware acceleration and OS rendering at the same<br>> time. It was a long time ago, so I've forgotten the exact configuration. I<br>> know SGI pipes were part of the mix. This was in the parallel VTK days;
<br>> ParaView did not exist, therefore no client/server architecture etc...<br>><br>> One application is rendering extremely large offscreen imagery using<br>> mangled Mesa (limited by memory)  and hardware accelerated rendering
<br>> smaller imagery for onscreen interactive use. This requires both libraries<br>> in the same executable.<br>><br>> Brian, what is the maintainence issue? What is the current cost etc.?<br>><br>> --Jim
<br>><br>><br>><br>> _______________________________________________<br>> ParaView mailing list<br>> <a href="mailto:ParaView@paraview.org">ParaView@paraview.org</a><br>> <a href="http://www.paraview.org/mailman/listinfo/paraview">
http://www.paraview.org/mailman/listinfo/paraview</a><br>><br>><br><br><br>--<br> Berk Geveci<br> Kitware Inc.<br> 28 Corporate Drive<br> Clifton Park, NY, 12309<br></blockquote></div><br>