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

[tom fogal]

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