Is there a way to speed up the saving of a figure in jpg format in nodisplay mode ?

I'm trying to save a figure as a jpg on a server without display.

The ''saveas'' function takes about 10s to save as jpg for image of ~200ko.

At first, I tried to save the image with another function like print but it's the same. (I think it might be a problem with writing to my disk, but after some tests I realised it wasn't that).

In the second part, I did some tests and played with the figure setting options like Visible, renderer... to finally understand that it is the renderer that is very slow, because in nodisplay mode, opengl cannot be used and the painters renderer is used. (opengl info gives a blank result). Testing the same code in matlab with display and set opengl renderer, it takes about 1s and with painters renderer, it takes about 10s. Why is there a big difference in time between opengl and painters renderer?

Is there a way to save the figure as an image faster in the matlab code?

Alternatively, maybe the solution is to use a tool unrelated to the matlab code to access an opengl renderer when running matlab?

I found out that we can use a virtual X server with xvfb to run matlab in display mode and use it to 'emulate' an opengl renderer, does this work well ?

Can we install a mesa3d tool on the server to use an opengl renderer without a graphics card or display for matlab?

Answer 1

[Richard Quist]

@Jean-Baptiste - the performance when exporting in no-display mode is often the result of having to rely on the painters renderer. For 2D scenes this is often not a big issue, but as the number of graphics objects grows the time can increase as well. For 3D scenes this can be more problematic.

Using something like xvfb may work but it's not something that has been tested. My guess is that using that would result in falling back to software OpenGL so there will likely still be a bit of a performance hit and there may be quality differences compared to hardware OpenGL, but it may be faster than painters.

Another option that may help a bit is to use the print() function and specify the -r0 option to export at the screen resolution... that would reduce some of the processing although the lower resolution may not be suitable for your use case. With a scene that has lots of graphics objects the performance impact of using -r0 may not be significant enough to warrant the change.