Closed scottwittenburg closed 5 years ago
ping @James-Crean @doutriaux1 @danlipsa @aashish24
Here I have added the screenshot capability requested in #52. You can save screenshots on the server or client or both, and it supports most of the image types I saw in vcs
(at least it handles png
, pdf
, svg
, and ps
). I tried adding unit support, but I removed it, as any type of units (other than None
) in combination with png
caused my vtkpython process to hang on both OSX and linux. I'll have to investigate that separately.
Included are some examples of how you could use this (see the demo application, instructions for running that are in our top-level README if you need). There is also a test that exercises the functionality. I wasn't sure how to add a test for server side screenshot saving, but it seems to work for me at least.
Let me know what you think.
I'm currently attempting to test locally with mesalib, as I am not seeing this error which is showing up on Travis:
*** Error in `vtkpython': malloc(): memory corruption: 0x00005624a4027780 ***
This seems to happen somewhere after the VTKPlots.py png()
method prints out its warning about saving a png of different size than the Canvas current size. Have you seen something like this before @danlipsa?
Oh! I saw that one last week! The non-mesa vtk version seems to seg fault on png
can you try to downgrad the build number of vtk-cdat?
wait! Yours is in mesalib? Ouch!
I don't think I fully follow you @doutriaux1. How can Travis test anything but the mesalib version?
So when I run these tests in a local nox
cdat8 conda environment, I get a segfault in the same spot as Travis hits that memory corruption message. So at least I have something to work with on my end ;-)
@scottwittenburg I cross read your original post, I thought it was on your machine.
@scottwittenburg I did update the vtk-cdat to a newer build try to bring in the previous build.
I see in the Travis output that it downloaded the following package:
vtk-cdat-8.0.1.8.0 | py27_mesalib_2 31.7 MB cdat/label/nightly
Do you think there is a way to get it to solve the environment differently to pick a different version? Like maybe in the travis.yml
mention vtk-cdat
specifically? Otherwise I'm not sure how to achieve what you're thinking.
I've discovered a strange thing that the same functionality that breaks the automated test (under mesalib
) runs just fine in the vcs-js
demo. Weird, but maybe it's a clue.
When I encounter the problem locally, I can look at my /var/log/syslog
and see the following line:
May 22 16:49:02 beast kernel: [25408.244427] traps: vtkpython[18038] general protection ip:7f638bbb4ebc sp:7fff84d94f20 error:0 in libOSMesa32.so.8.0.0[7f638b6f1000+188c000]
... still digging.
So I generated a core dump from one of the segfaults and looked at it with gdb. Since it seemed like renderWindow->SetSize() was implicated in the backtrace, I just took out the resizing form of the png generation in the automated test, and it stopped failing on my machine. Pushing that to github also allowed the test to pass on Travis.
However, there may be some underlying issue with the resizing png call when running in a mesalib environment. We should probably look into that only after we can start using the latest VTK
.
Any progress on this?
@sterlingbaldwin I haven't done any more since my last comment, but I will revisit again when the Context2D work in vcs is done and we can finally bring the latest VTK. Until then, you may be able to pull this branch, rebase it, and test it out to see if it does what you want.
All the features I was initially planning to add are here (saving on client and/or server, saving any export format vcs can handle, e.g. pdf, ps, svg, png, saving at different resolution than last plotted). You can look at both the example in demo.js
and the test in test/cases/vtkweb.js
to see how to make use of the functionality.
The only issue I encountered (which kept me from merging) was when running in a mesalib environment and using the png screenshot functionality with the resize parameters. In that case, the server does another plot at the desired resolution before sending the screenshot to the cliient, and that caused some exception. But under other use cases (not mesalib, or just accepting the last rendered image size), it was working ok.
That all sounds good, not merging until the latest VTK is in makes sense. Thanks for the update!
Add a test to the test cases and a couple of example usages to the demo as well.