[TTPrograms]

You probably want to compress your figures - I think your line plots are stored in some vector format. The paper is 30MB and rendering chokes on those ultra dense figures (and the data resolution is not buying you any information). If the figures are vector format you should convert to png/jpeg etc.

[jiayaozhang]

Thanks for the heads-up! Yes, we use vector graphics in pdf formats for all figures (outputted from matploblib). I overlooked the size of the arXiv version but my local complication is around 14.5MB (pdflatex under TexLive 2020). I will check what went wrong :)

[godelski]

You should keep the vectored graphics for research papers, it is really handy so people can zoom in. The issue here is just how much information is in the plots you have. E.g. Figure 3 each subplot contains a lot more information than is actually needed. You could use moving averages there to clearly state the same thing. Or if you wanted to, you could include the envelopes. That would create smaller sized images. The other option is to just make the plots more sparse. There's far more information than necessary there.

It's weird, but images often sell a paper, so it is worth time learning how to make good images (or at least one person in your group). But that said, research comes first and that is more important. Just don't underestimate the power of good images. I often find this video on colors helpful[0]

[0] https://www.youtube.com/watch?v=Qj1FK8n7WgY

[go_elmo]

Maybe pdf graphics would cost less? Keeping it scalable would be great

[knuthsat]

I'd say this is a problem with the PDF reader, not the paper.

Why is PDF reader having trouble displaying 30MB of data?

It's even better than a 30MB of images, because images have to be decoded but vector graphics is just bytes at some point and you decide how to render them.

It's probably some accidentally quadratic behavior that struggles with 10000 vector objects.

[ishitatsuyuki]

Vector graphics are much more complicated than raster images. They have to be drawn sequentially (to not mess up draw and blending order), mostly on CPU with the current software stack. And no, at 30MB you are looking at about 100000 paths, each of which consists of bezier curves which needs to be converted into polylines before drawing (there are algorithms that handles curves directly, but they are just as expensive). It's a vast amount of workload.

Images are relatively well handled with GPUs, and with a precomputed mipmap they can be rescaled very quickly, unlike vector graphics which needs to be re-rendered each time zoom level is changed.

[knuthsat]

Yeah, handling 100k paths on CPU means the problem is in the PDF reader, not the PDF. Although I must admit that calculating 100000 paths and getting polylines still shouldn't take very long.

Why wouldn't you be able to send an array of stuff defining the curves, and an array of stuff defining the draw order to the gpu and just render it in a simple?