I have a VTK Web application and I was wondering the best way to install the vtk web requirements. I am looking at Docker and/or pip solutions.
For Docker, it does not seem to have vtk web docker anymore, only Paraview with the pvw tag. Could I use it directly and simply ignore the paraview components?
For Pip, is the web component shipped inside the wheel? Is there a way to choose between egl and osmesa?
Is there any other solutions? I guess compiling from sources is always one
So the latest vtk does not have any wheel for osmesa or egl but ParaView does and can be use to run vtk code. (We are trying to figure out a solution to have other vtk wheels with egl…)
In general, for deploying a vtk/pv web application we rely on Docker to offer a built-in system for serving multiple users on a given machine.
For trame we built new docker images that only install the network and python runtime. Then we rely on an “external” virtual env to install all the “app specific” python packages. This means, you can use them for your vtk web as well.
If you want to see an example for remote rendering with EGL, you can look at our docker setup for visualizer. For you, since you have a custom client (html/css), you will need to provide it inside the directory ./setup/www/*. You will also have to tweak the command line defined in your app.yml file.
Technically, this will build a ./server/ directory with the generated launcher configuration along with the virtual-env for your application.
Thinking about it more, since you are not using trame, you may run into some issue when the image try to fill the ./server/www/* directory. But you might be able to bypass that by having an empty ./setup/apps.yml file and manually editing the launcher configuration inside the server directory after the first run.
Or you can also use the “old” paraviewweb images.
Great news for the wheels using osmesa and co. Do you have an idea of when we could test the first wheel? Like in the year, more or less? Just to have an idea of your timeline on this.
Well there is another cool feature that is in the pipe that we hope to leverage for the next release of vtk (next 3 months I think), which is to use EGL for either GPU or CPU rendering. This mean, we should be able to have a single wheel for offscreen and just be able to rely on the hardware if available. My hope, is that we will create such “offscreen” wheel for the release of vtk 9.2.
@ben.boeckel and @Chuck_Atkins are the ones to thanks for that. Also we might not be able to publish the egl one on PyPI but we should be able to have it downloadable from our website.
EGL offscreen will likely be a post-release thing. PyPI wheels cannot provide it until libEGL is allowed to be not provided by wheels (like libGL, libX11, etc.).
It might be a good idea to build your own osmesa version regardless of us managing to release an egl wheel or not during the current release process.
What Ben is mainly talking about it is related to the fact that we won’t be able to publish a VTK-EGL build to PyPI. Which is fine as we were just targeting a downloadable version of it on our website.
Then the second aspect of having an EGL build which can be either GPU accelerated and fallback to mesa CPU when a GPU is not available. Well after talking to Chuck, it might be more reasonable and more portable to just do an EGL build without mesa to prevent any possible conflict and only rely on a proper system install of mesa-egl. This just mean that we will not provide a VTK for EGL+mesa but just VTK for EGL and maybe guideline on how to build mesa-egl so that VTK version can work on a CPU only system.
Ideally that also mean that for VTK/ParaView Web we might be able to create docker image that could work with or without GPU by bundling mesa-egl. But I guess we will have to see how that is going work.
With time things may change and we may end up having a path where we bundle everything, but it might be with something like conda. But I guess we will have to see.
So having offscreen solutions for VTK/Python is definitely on our roadmap but it is hard to provide a real timeline for those things.
I was personally hoping that the current release process could give enough time for Ben to work on those new builds. But it may not happen and such work may have to be postpone until Ben has more time for it. Hence the post-release possibility.
