Making the package jmol optional

112 views
Skip to first unread message

Matthias Koeppe

unread,
Dec 7, 2020, 12:11:31 AM12/7/20
to sage-devel
In https://trac.sagemath.org/ticket/30315 I propose to make jmol optional. To my understanding it has been replaced by generally better options such as threejs and jsmol. But it's possible that I'm missing something.

The Javascript version of it, previously installed as part of jmol, is switched on this ticket to come from the pip-installable package jupyter-jsmol.


Antonio Rojas

unread,
Dec 7, 2020, 4:25:25 AM12/7/20
to sage-devel
El lunes, 7 de diciembre de 2020 a las 6:11:31 UTC+1, Matthias Koeppe escribió:
In https://trac.sagemath.org/ticket/30315 I propose to make jmol optional. To my understanding it has been replaced by generally better options such as threejs and jsmol. But it's possible that I'm missing something.

The Javascript version of it, previously installed as part of jmol, is switched on this ticket to come from the pip-installable package jupyter-jsmol.

Is there any reason for not making jsmol optional too? Isn't three.js the default renderer these days?
 

François Bissey

unread,
Dec 7, 2020, 4:26:46 AM12/7/20
to sage-...@googlegroups.com
three.js still cannot be used to build the doc as far as understand.

Eric Gourgoulhon

unread,
Dec 7, 2020, 4:57:22 AM12/7/20
to sage-devel
Indeed, this is currently the major drawback of Sage's three.js viewer: it cannot generate png images in an automatized way (in interactive mode, there is no problem: it suffices to click on "Save as PNG" in the three.js menu).  As a consequence, all the 3D plots shown at https://doc.sagemath.org/html/en/reference/plot3d/sage/plot/plot3d/plot3d.html are generated with jsmol. A drawback here is that these images do not correspond to what the end user will get in his Sage session.

Eric.

Eric Gourgoulhon

unread,
Dec 7, 2020, 5:02:51 AM12/7/20
to sage-devel
Moreover these 3d images are static; it would be nice to have (at least some of) them interactive, as in

Eric.

Dima Pasechnik

unread,
Dec 7, 2020, 5:22:36 AM12/7/20
to sage-devel
isn't it something to ask the 🌲.js upstream for, a non-interactive png export?

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c27c7737-3bba-486c-a3a2-32617c14e8dfn%40googlegroups.com.

Sébastien Labbé

unread,
Dec 7, 2020, 6:51:46 AM12/7/20
to sage-devel
At some point in time, tachyon was used to generate static images of Graphics3D objects. Why isn't not possible to use tachyon for the images in the doc instead of jmol?

Eric Gourgoulhon

unread,
Dec 7, 2020, 8:47:54 AM12/7/20
to sage-devel
Le lundi 7 décembre 2020 à 12:51:46 UTC+1, Sébastien Labbé a écrit :
At some point in time, tachyon was used to generate static images of Graphics3D objects. Why isn't not possible to use tachyon for the images in the doc instead of jmol?

Technically, this is easy: it suffices to change the following part of method Graphics3d._save_image_png() (lines 1587-1588 of src/sage/plot/plot3d/base.pyx):
        if viewer == 'threejs':
            viewer = 'jmol'  # since threejs has no png dump
into
        if viewer == 'threejs':
            viewer = 'tachyon'  # since threejs has no png dump

However the drawback mentioned above would remain: the plots shown in the doc would be different from those that the user gets on his screen, especially since Sage's three.js viewer is well advanced now and has many rendering options that neither jmol nor tachyon have.

Eric Gourgoulhon

unread,
Dec 7, 2020, 8:53:37 AM12/7/20
to sage-devel
Le lundi 7 décembre 2020 à 11:22:36 UTC+1, dim...@gmail.com a écrit :
isn't it something to ask the 🌲.js upstream for, a non-interactive png export?

Yes this sounds like something to do. I remember however that there was a discussion about some security issues in such a process. Maybe Paul Masson or Joshua Campbell can comment upon this?

Dima Pasechnik

unread,
Dec 7, 2020, 9:01:58 AM12/7/20
to sage-devel
I am confused now - how on Earth the latter interactive plots were
produced then, if not with threejs used within Sage?
Why can't this technique be used with other plots ?

It's also not clear why three js cannot be used for non-interactive
png generation, this seems to be a lack of some js code in Sage to
do so rather than anything else, see e.g.
https://stackoverflow.com/questions/40444995/how-to-convert-render-from-three-js-to-png-file

Dima

PS. I'll be teaching an intro to computer graphics course from
mid-January, I'm supposed to become an expert on this stuff
any moment now :-)

Eric Gourgoulhon

unread,
Dec 7, 2020, 10:08:10 AM12/7/20
to sage-devel
Le lundi 7 décembre 2020 à 15:01:58 UTC+1, dim...@gmail.com a écrit :
On Mon, Dec 7, 2020 at 10:02 AM Eric Gourgoulhon <egourg...@gmail.com> wrote:
>
>
>
> Le lundi 7 décembre 2020 à 10:57:22 UTC+1, Eric Gourgoulhon a écrit :
>>
>> Indeed, this is currently the major drawback of Sage's three.js viewer: it cannot generate png images in an automatized way (in interactive mode, there is no problem: it suffices to click on "Save as PNG" in the three.js menu). As a consequence, all the 3D plots shown at https://doc.sagemath.org/html/en/reference/plot3d/sage/plot/plot3d/plot3d.html are generated with jsmol. A drawback here is that these images do not correspond to what the end user will get in his Sage session.
>
>
> Moreover these 3d images are static; it would be nice to have (at least some of) them interactive, as in
> https://doc.sagemath.org/html/en/reference/plot3d/threejs.html

I am confused now - how on Earth the latter interactive plots were
produced then, if not with threejs used within Sage?
Why can't this technique be used with other plots ?

These interactive plots have not been automatically generated while building the doc, but have been prepared by hand and are stored in
src/doc/en/reference/plot3d/threejs_examples
They are included into the doc by  src/doc/en/reference/plot3d/threejs.rst

Matthias Koeppe

unread,
Dec 7, 2020, 1:11:03 PM12/7/20
to sage-devel
On Monday, December 7, 2020 at 1:57:22 AM UTC-8 Eric Gourgoulhon wrote:
Le lundi 7 décembre 2020 à 10:26:46 UTC+1, François Bissey a écrit :
> On 7/12/2020, at 10:25 PM, Antonio Rojas <nqn...@gmail.com> wrote:
> Is there any reason for not making jsmol optional too? Isn't three.js the default renderer these days?

three.js still cannot be used to build the doc as far as understand.

Indeed, this is currently the major drawback of Sage's three.js viewer: it cannot generate png images in an automatized way (in interactive mode, there is no problem: it suffices to click on "Save as PNG" in the three.js menu).  As a consequence, all the 3D plots shown at https://doc.sagemath.org/html/en/reference/plot3d/sage/plot/plot3d/plot3d.html are generated with jsmol. [...]

Would it be possible to run three.js (and/or jsmol) in node.js for this (i.e., outside of the browser)? We already have nodejs and nodeenv packages in Sage (for JupyterLab).




 

Joshua Campbell

unread,
Dec 7, 2020, 1:27:24 PM12/7/20
to sage-devel
The "Save as PNG" feature already uses the technique you linked to, but it may require user interaction to complete; you may be prompted to choose whether/where to save the file. It also requires the page to be open in a browser window in the first place.

In the past, I looked into trying to use headless mode for both FireFox and Chrome. Both allow you to pass in a URL and have a screenshot of the page's contents generated without opening any windows or requiring any user interaction. But IIRC, I ran into security issues trying to access local files as well as problems with the screenshots failing or being blank due to WebGL not working in headless mode. The security issues might be solved by serving the files from a simple HTTP server running locally, but I'll have to look into the current state of headless WebGL.

I suppose an (incredibly hacky) alternative could be to spin up an HTTP server that takes requests containing PNG data and writes them to disk. For each plot page, launch it in a new, isolated browser process, pass some sort of "docbuild" flag to the page in the querystring, have the page automatically send a request to the server with the output of toDataUrl once its finished rendering its first frame, then kill the browser process. Sit back and enjoy the show as browser windows appear and disappear, and pretend like you're back in the late 90's waging one of those hopeless wars against an unending swarm of pop-up ads :)

Matthias Koeppe

unread,
Dec 7, 2020, 1:34:15 PM12/7/20
to sage-devel

Joshua Campbell

unread,
Dec 7, 2020, 1:45:58 PM12/7/20
to sage-devel
Interesting... I especially like the animated gifs. I will play around with it later today.

Seems like a decent bit of refactoring of the three.js viewer, though, to rip out the javascript that would be shared by these new nodejs scripts and the regular HTML pages.

Joshua Campbell

unread,
Dec 7, 2020, 4:33:09 PM12/7/20
to sage-devel
Hmm... no joy. Although it's "headless" in the sense that it doesn't require a browser, it still seems to require a graphical environment of some sort. It doesn't work on my Ubuntu WSL install, nor does it work on my Arch Linux box from the virtual console, even with X running in another. It only works from a terminal within the X environment, so it doesn't seem suitable for automated builds. I'm curious if others can replicate my findings.

(Out of curiosity, I decided to test FireFox in headless mode, and it does work without starting X.)

Jason Grout

unread,
Dec 7, 2020, 6:14:25 PM12/7/20
to sage-devel
https://github.com/plotly/Kaleido is an interesting new project for generating static images from a browser rendering library that may be useful here (I'm not sure if it handles webgl, though).

Jason


--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

kcrisman

unread,
Dec 7, 2020, 7:37:30 PM12/7/20
to sage-devel
Any progress here might also be useful for alternate (3d) image generation for SageTeX, which currently would (I believe) continue to rely on jmol proper for that purpose. 

Joshua Campbell

unread,
Dec 7, 2020, 8:44:30 PM12/7/20
to sage-devel
Thank you, that library looks very promising. I'll try to find some time to play around with it, though it looks like a good bit of work to extend (and build!)

Matthias Koeppe

unread,
Mar 16, 2022, 2:34:04 PM3/16/22
to sage-devel
Reviving this old thread...
Another option is https://github.com/puppeteer/puppeteer, which is used by screenshotting tools such as https://github.com/marketplace/actions/screenshots-ci-action

Michael Orlitzky

unread,
Mar 16, 2022, 9:08:27 PM3/16/22
to sage-...@googlegroups.com
On Wed, 2022-03-16 at 11:34 -0700, Matthias Koeppe wrote:
> Reviving this old thread...
> Another option is https://github.com/puppeteer/puppeteer, which is
> used by
> screenshotting tools such
> as https://github.com/marketplace/actions/screenshots-ci-action
>
> I've opened https://trac.sagemath.org/ticket/33513 for this
>

Despite being a standard package, any attempt to use jmol here has
always returned

RuntimeError: jmol cannot run, no suitable java version found

If that's OK, then not installing it in the first place should also be
OK. Just mark it optional and sprinkle some "(requires jmol)" on the
docs.


Reply all
Reply to author
Forward
0 new messages