Some ideas

[erikkemperman]

So I've been playing around with dooble for a while, really nice work!

I have some ideas, but would like to discuss a bit -- don't want to put too much effort into things that you might not like...

• On MacOS the default matplotlib is interactive, I think it might be good to default to non-interactive backend.
• Actually, it might be good to use different backends for different image formats -- I think it would be nice, for example, to use .svg images for the html documentation and .eps images for latex.
• Can we set the minimum required matplotlib to version 3, since python2 is not supported by dooble anyway?
• If a large number of marble diagrams are being rendered, things get kind of slow. I think it would be nice to implement a sort of "batch" or "async" mode, using multiple threads and/or processes.

Curious what you think!

[MainRo]

* On MacOS the default matplotlib is interactive, I think it might be good to default to non-interactive backend.

We could change that but dooble does not use interactive rendering anyway. So I am not sure what would be the benefits. Also I am not sure whether the agg backend is available on all systems (need to check). If yes, we may force it if there is some benefit expected (obviously faster load time and/or rendering is a big one).

* Actually, it might be good to use different backends for different image formats -- I think it would be nice, for example, to use .svg images for the html documentation and .eps images for latex.

Different backends or different file formats ? BTW if you provide another extension than png, then the current code will generate another format according to the extension. I did not document it because it is a implicit feature, hence not desirable. We should expose a -t option to specify the expected image format, independently from its name (and default to png for compatibility).

* Can we set the minimum required matplotlib to version 3, since python2 is not supported by dooble anyway?

yes, I do not remember why I did not use it but sticked to 2.2 instead. I need to check this.

* If a large number of marble diagrams are being rendered, things get kind of slow. I think it would be nice to implement a sort of "batch" or "async" mode, using multiple threads and/or processes.

For me this is out of scope of dooble itself, but should be handled in applications using dooble (e.g. the sphinx extension): The current cli can be typically used in a makefile. Adding multi-threading would imply providing multiple files as input and multiple files as output. In the case of something similar to makefiles, multiple instances of the dooble cli can run in parallel. In the case of something like sphinx, then several threads can use the dooble API (this is done by sphinx).

[erikkemperman]

Sorry, I appreciate your detailed response but did not get around to processing it.

We could change that but dooble does not use interactive rendering anyway. So I am not sure what would be the benefits. Also I am not sure whether the agg backend is available on all systems (need to check)

So I think the agg makes sense, because it's a bit annoying on MacOS that a separate and unnecessary process is started (a Python GUI) when rendering marbles. I just checked that it works for all the major platforms, and will submit a PR: .

yes, I do not remember why I did not use it but sticked to 2.2 instead. I need to check this.

Not sure if this is actually very important, but it turns out that 3.0.3. works well: link. I'll submit a PR but please feel free to ignore it.

Different backends or different file formats ?

Yes, I was thinking that "specialized" backends might do a better job of rendering different formats, so for instance that the ps backend might be better at rendering .eps then the more generic backends.

I understand your point about not explicitly supporting different formats though, but I think that for the sphinx documentation of Rx it would be nice to use .eps images for the latex build and use .svg for the html build.

But maybe that's not worth it...

[MainRo]

So I think the agg makes sense, because it's a bit annoying on MacOS that a separate and unnecessary process is started (a Python GUI) when rendering marbles. I just checked that it works for all the major platforms, and will submit a PR: .

Can you precise what you mean by "a python GUI" ? There is a window appearing or something like that ? Setting the backend to Agg will probalbly also allow to run dooble from a virtualenv (the macosx backend exits when it is started from a virtualenv)

Concerning the better rendering in latex I will try to look at this before the rxpy v3 release because many parts of the doc are not correctly rendered in the pdf output.

[erikkemperman]

It “almost” shows a window. What happens is it switches workspace (I have my ide on a separate one) and it adds an entry to the task switcher (python logo). Then it writes the file, and closes the almost-a-window before anything is displayed.

When generating a bunch of marbles, as in building the rx docs, this happens very often :-)

About the alternate backends for various types, I think .eps would best suit the latex builds. I tried pdf as well, didn’t notice anything wrong but probably haven’t seen the examples you’re thinking of.

[erikkemperman]

Ah, sorry, I guess you meant pdf as in the final Sphinx output, not as an image format for individual marble diagrams. Disregard my last comment...