[vtk-developers] Use (`new') GLEW in VTK?

[tom fogal]

Ping!

I imagine this initially went out while many were on vacation.  Hoping
people are back now...

-tom

tom fogal <tfogal at sci.utah.edu> writes:
> Hi,
> 
> I'm forwarding this along again, without the patches attached, because
> they made the message so large that it got stuck in a moderation queue.
> 
> -tom
> 
> ------- Forwarded Message
> 
> Reply-To: tfogal at sci.utah.edu
> From: tom fogal <tfogal at sci.utah.edu>
> To: vtk-developers at vtk.org
> cc: pugmire at ornl.gov
> Subject: Use (`new') GLEW in VTK?
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
> Content-ID: <3675.1293055749.0 at shigeru.sci.utah.edu>
> Date: Wed, 22 Dec 2010 15:10:12 -0700
> 
> - ------- =_aaaaaaaaaa0
> Content-Type: text/plain; charset="us-ascii"
> Content-ID: <3675.1293055749.1 at shigeru.sci.utah.edu>
> 
> I've been working on a VTK hack in recent days, and given the "Render
> tests ... Mesa features" thread, I figured now was a good time to bring
> it to light.
> 
> I'm working with the VisIt team and trying to help figure out our best
> route forward with a long-overdue VTK upgrade.  One of the issues we
> hit is with offscreen rendering.  It seems the `system' GL + Mangled
> Mesa setup has been allowed to atrophy in recent versions of VTK.  This
> puts us in a bit of a bind, as the feature is critical for us.
> 
> For various reasons, we must delay the choice of GL library until
> runtime.  Thus any sort of compile-time solution (i.e. building one
> "Mesa+VTK-based binary" and one "GL+VTK-based binary") isn't going to
> work for us.  We also hit the issue that GLEW 1.x -- which we use for
> some of our code that performs custom rendering -- was making the above
> choice at compile-time.
> 
> We've been working with GLEW upstream to get a version of GLEW that
> does not utilize an OpenGL library at compile-time at all.  Instead, it
> dlopen()s (or similar) the GL library and loads function pointers that
> way.  This would obviate the need to even link an OpenGL library at
> all.  This modified version will turn into GLEW version 2 in the first
> quarter 2011.
> 
> We'd like to get VTK doing the same thing we do.  I attached a (hacky)
> patch series that should give you the gist of what we're thinking
> about.  There's some things still missing (notably, the CMake machinery
> to avoid linking -lGL or -lMesaGL at all), but I tested a couple of
> the VTK example programs and they seem to be okay.  We could speak at
> length about what's still needed and why this is a Good Thing, if you'd
> like (given the aforementioned thread -- one nice bonus: just set an
> env var or command line option, and you can test with a new GL: no
> recompilation required!).
> 
> I'd like to appeal to the VTK developers that we adopt a
> corrected-version of the attached patchset into VTK.  We (the VisIt
> team) have had a lot of custom hacks to VTK over the years, and,
> frankly, most if not all of us hate it.  We'd really like to start
> aligning a bit better, and now seems like a great time, since we are
> contemplating a VTK upgrade.
> 
> The patch series is also available online, if you prefer that:
> 
>   http://shigeru.sci.utah.edu:1234/?p=vtk.git;a=summary
>   git://shigeru.sci.utah.edu/vtk.git
> 
> Thanks for your consideration,
> 
> - -tom
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource
> /opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers