Re: bits about the future with VTK in Buster
Hi Gert,
thanks for the info and analysis! Well, to make a decision
we should firstly check how many packages are not able
to be built "out of box" with the new backend. Than we can
decide what to do with this rest of packages.
I do not like the idea to keep both versions of VTK parallely,
it can cause many unpredictable conflicts.
And yes, we have the time between releases to make major
changes in packages.
Best regards
Anton
2017-04-06 10:27 GMT+02:00 Gert Wollny <gw.fossdev@gmail.com>:
> 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: