Re: bits about the future with VTK in Buster
On Thu, 2017-04-06 at 10:27 +0200, Gert Wollny wrote:
> Hello all,
>
> I just drop this here for future reference.
Thanks for looking into it and summarizing your findings.
> I've experimented a bit with VTK-7.1 and among other, minor issues I
> came across the problem that VTK now defaults to, and, hence,
> encourages the use of, a new renderer backend, called OpenGL2 that
> requires an OpenGL 3.2 context. The old OpenGL renderer is still
> available in the code, but when compiling VTK one can only enable one
> or the other.
Ack.
> Now, OpenGL specifies a compatibility profile that would provide the
> legacy fixed function interface also with the new >=3.2 context, but
> Mesa doesn't implement it, which means, code written against the old
> style OpenGL API will not run properly when a 3.2 OpenGL context is
> used (as required by the VTK OpenGL2 backend), even if the
> incompatibilities between the VTK renderer class interfaces could be
> patched.
>
> Also, code using the new renderer will not run on older graphics
> hardware, since VTK then simply rejects pre-OpenGL 3.0 contexts.
Well, I guess we will have to draw a line in the sand at some point
about old hardware compatibility. Are there that many people running
something as intensive as paraview on a very old laptop, I wonder?
> One example that uses VTK, but it also has lots of old-style OpenGL
> code in it is ginkgocadx, which means it can not run properly with VTK
> with the new renderer is enabled. ginkgocadx has been abandoned by
> upstream, and I started to maintain it and try to keep the code up to
> date. The last few days I tried to port it to OpenGL >= 3.2, but it is
> a big task, since toe code is littered with old-style openGL, so I
> don't really see it being done, and I guess it is similar for other
> projects that use VTK. I could imagine that even for software that is
> actively maintained the developers may be reluctant to switch to the
> new renderer if it contains too much non-VTK OpenGL code (I checked,
> and at least with version 3.4 itksnap also uses some direct calls to
> old-style OpenGL).
>
> On the other hand we can expect that some software will start to rely
> on the new OpenGL2 renderer at which point we have a problem if we
> don't want to keep two versions of VTK in the archives.
I wonder whether we could keep VTK-6 for projects using the old API and
force VTK-7-only projects to use the new one? VTK-6 and VTK-7 should be
co-installable, right?
Ghis
Reply to: