When interacting with a large dataset (e.g. 30 GB), there is significant lag between interaction and response. This does not occur when using Enchiladas alone, only when running within Tapestry. Adding multiple containers doesn't seem to help much.

In the current version of Enchiladas (22bca3b49818b65bbfdd904cc8dd9a7842ffa277), we seem to have a bug with the JavaScript code for tapestry.js (permalinked and highlighted here):

        $(this.element).on("mousemove", function(){
            self.canceler = (self.canceler + 1) % 1000;
            if (self.canceler % 5 == 0)
            {
                var mouse_x = event.clientX - self.element.getBoundingClientRect().left;
                var mouse_y = event.clientY - self.element.getBoundingClientRect().top;
                self.rotate(mouse_x, mouse_y, 1); // Render low quality version
            }
        });

The name of the upstream in nginx is hard coded to "tapestry". We don't use docker compose but something like "links" from docker compose should be used as a solution.

Note: Environment variables cannot be used in the upstream tag in the nginx configuration.

User request.

Right now we do a naive submodule check (if the directory exists, submodules have been pulled in), but we need a better one. When you clone (without --recursive), it still creates the directories, so the script incorrectly assumes they've been pulled in.

An easy fix might be to just always call git submodule update --init, but we'll have to check.

At the moment, scrolling doesn't work in Firefox and it also breaks things in Internet Explorer 11.

Request from users.

Maybe add something like echo $(cd $(dirname $filepath); pwd)/$(basename $filepath) to all mounts in tapestry.sh?

Some installation issues that have been noted by users:

• pip is only installed if minifyjs is enabled
• ispc and embree links are sometimes not working
• check to see if we have to clone with --recursive or not

User request.

Your paper was really interesting to read and investigating a stateless server for dynamic rendering definitely seems interesting.

But I wanted to add a couple comments.

You did cover ParaViewWeb/Visualizer+LightViz but missed ArcticViewer which rely on pre-generated images (in some cases) which allow dynamic interaction on the client side without any specific server requirement and therefore will scale without putting any burden on the viewing resource.

You can find the original web site here: https://kitware.github.io/arctic-viewer/

And some usage here: https://openchemistry.github.io/tomvizweb/
The image based one: https://openchemistry.github.io/tomvizweb/docs/images_volume_exploration.html

Anyway great work!

User request.

User request

The dataset name for the teapot example is incorrectly set to magnetic. The turbulence json should also be double-checked.

User request.