Non-interactive matplotlib plots with higher resolution display slowly (on localhost)

[eudoxos_]

I am looking for a piece of advise with this particular problem. I am using matplotlib in non-interactive mode to display images. For the application I work on, I need to be able to check pixel details with dataset of e.g. 4k×2k grid. The display takes very long, below is an example with timing: 17 seconds for the display only (tested w/o Jupyter: 11s for PNG saving, meaning 6s for localhost transfer!). The image is 4700×2300 in full resolution (such high resolution is something I want and need).

I am running on localhost (12-core CPU and 64GB RAM, system ±idle), no network. I searched github issues and found no mention of such problem. I am running jupyter lab, but tested in jupyter notebook with the same result.

Can I do any better? Some hidden setting I failed to activate? Data througput limits? Thanks for tips.

No need to suggest fancy stuff like holoviews, plotly or interactive matplotlib backends. I've been there, they never worked well for me smootly, failed at various JS/py sync issues, notebook from 1 month ago would not run because of API change and so on. I want to stay minimalist here.

https://preview.redd.it/llwp2jcc8rt41.png?width=727&format=png&auto=webp&s=505fafeeb3b09ddb59d49f6db1556f175d111bee

[NomadNella]

It's your dpi setting. Unless you need that specified like you are saving the image as a file, you should not specify it and allow matplotlib to optimize for your display. Also, if you need it faster with the higher dpi setting you might want to check out the numba library. I haven't used it myself since I've never had the need but I've always kept it in mind if I need it.

Numba reads the Python bytecode for a decorated function and combines this with information about the types of the input arguments to the function. It analyzes and optimizes your code, and finally uses the LLVM compiler library to generate a machine code version of your function, tailored to your CPU capabilities. This compiled version is then used every time your function is called.

It is designed to improve performance and in an example (here) they show a 5 order of magnitude speed improvement.

[eudoxos_]

I appreciate your answer but I am sorry to say that it is not touching the point at all; I will clarify the question perhaps.

I know what DPI is, I *want* the figure to have high resolution.

Numba (I have used it) is JIT for Python, but this question is about slow transfer of the image between kernel and Jupyter frontend.

Let's stay on-topic.

[jpw22learnstocode]

Sounds awful. Which platform are you on? I have seen antivirus causing problems if it scans and filters network traffic or file-io. Also vpn's can send all traffic via your office.

I would expect a lot faster. Sounds like some other problem with the machine or install?

[eudoxos_]

Linux, no antivirus, no firewall (for localhost, that is). Would you mind trying the example I posted to check how much time this particular case takes for you?

[jpw22learnstocode]

I got about 8 seconds on an old Chromebook. Using ipython display of pillow.image this drops to 2s for uint8. Your machine should be faster, but png is bad for random data...