bits about the future with VTK in Buster
Hello all,
I just drop this here for future reference.
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.
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.
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.
Well, Buster is still two years away ...
Best,
Gert
Reply to: