nertskull <nertskull@...287...> writes:
If I change that line the "if True:" then I get MUCH better results.
But I also get enormous file sizes.
That's interesting! It means that your pdf viewing program (which one,
by the way? Adobe Reader or some alternative?) is slow at compositing a
large number of prerendered markers, or perhaps it just renders each of
them again and again instead of prerendering, and does so more slowly
than if they were part of the same path.
I've taken a subset of 10 of my 750 graphs.
Those 10, before changing the backend, would make file sizes about about
290KiB. After changing the backend, if I use plot(x, y, '-') I still
get a file size about 290KiB.But after changing the backend, if I use plot(x, y, '.') for my markers,
my file size is no 21+ MB. Just for 10 of my graphs. I'm afraid making
all 750 in the same pdf may be impossible at those size.
Does using ',' (comma) instead of '.' (full stop) as the marker help? I
think the '.' marker is a circle, just at a small size, while the ','
marker is just two very short lines in the pdf backend. If the ','
marker produces an acceptable file size but its shape is not good
enough, we could experiment with creating a marker of intermediate
complexity.
One thing that I never thought about much is the precision in the
numbers the pdf backend outputs in the file. It seems that they are
being output with a fixed precision of ten digits after the decimal
point, which is probably overkill. There is currently no way to change
this except by editing the source code - the critical line is
r = ("%.10f" % obj).encode('ascii')
where 10 is the number of digits used. The same precision is used for
all floating-point numbers, including various transformation matrices,
so I can't offer a simple rule for how large deviations you will cause
by reducing the precision - you could experiment by making one figure
with the existing code and another with '%.3f', and see if the latter
looks good enough at the kind of zoom levels you are going to use (and
if it really reduces the file size much - there's a compression layer on
top of the ASCII representation).
That reminds me: one thing that could have an effect is the
pdf.compression setting, which defaults to 6 but you can set it to 9
to make the compressed size a little bit smaller, at the expense of
spending more time when writing the file. That's not going to be a major
difference, though.
Is there anyway to have reasonable pdf sizes as well as this improved
performance for keeping them in vector format?
Like others have recommended, rendering huge clouds of single points is
a problematic task. I think it's an entirely valid thing to ask for, but
it's not likely that there will be a perfect solution, and some other
way of visualizing the data may be needed. Bokeh (suggested by Benjamin
Root) looks like something that could fit your needs better than a pdf
file in a viewer.
···
--
Jouni K. Sepp�nen