Improve memory handling

[dannyedel]

This should fix #140 - not only on windows.

• This PR adds a command line switch --cache-size, which is enforced by QCache.
  • While the current memory usage estimate is rather dumb (32bit * width * height) it does serve to prevent limitless growth.
• This avoids creating one Poppler::Document per thread, instead adding a mutex to a creation section and let the threads share a QSharedPointer<Poppler::Document const>.
• Also adds a WARNINGOUT macro, similar to DEBUGOUT.
• If there are RenderThreads still waiting to start and the application is shut down, they will now fail their rendering instantly. (The user won't see it anyway...)

[dannyedel]

@projekter, could you build this branch on Windows and verify if it (a) works and (b) uses less-or-equal RAM than master?

On my Linux box, calling it like ./dspdfviewer --prerender-next=100 testing/many-many-pages.pdf crashed when RAM-limited to 1.5GB (before) but now it works correctly (starts dropping pages).

If it builds correctly, it would be cool if you could publish it at the windows release page as a pre-release again, also so that @raissel can get the presentation going : )

[projekter]

I built it and it seems to work. But for some reason, the tests currently fail to build, so I uploaded this one as a pre-release and will try to figure out what's the problem with them in the afternoon. On my VM with very limited RAM, the large test document loads without problems, although when being on the last page, the machine's RAM is almost filled. I tested both versions with my large presentation: The new one requires 426 MB for ~ 20 open pages, while the old one only acquires 260 MB. So it doesn't seem to improve, but @raissel, perhaps it works for you.

[dannyedel]

the tests currently fail to build

Any specific failure messages?

The new one requires 426 MB for ~ 20 open pages, while the old one only acquires 260 MB.

The previous logic counted cache size in "number of images", where a thumbnail counted the same as a full render. Thats why the RAM usage was so unpredictable. It is quite possible that in your case the cache was "full" in the old logic (number of images), but not in the new. I changed it so the image size is the main weight in calculating cache cost, but I set the default cache size to 1GB. If you start dspdfviewer with --cache-size=100 (or in the config) the RAM usage should be notably less.

I added one more change to the cost counting, for me (64-bit Linux) the total RAM usage of dspdfviewer now stops at ca. 100MB plus cache size.

[dannyedel]

I merged this into master to make it easier for me to rebase the fresh tests I'm writing.

@projekter: If you have any patches for the windows port, please open a new PR to master.

[projekter]

The patch is done (see #143); I wonder why it built successfully on your machine, as it was a namespace resolving problem. Including your latest fixes, memory consumption is even bigger. The same PDF as before now requires ~ 580 MB. But as soon as the default limit is reached (~ 1,1 GB), there are no new allocations. I also tried setting the limit to 100 MB, which makes the whole presentation a very unpleasant experience. Every page is loaded very slowly, first shown as a thumbnail, then being increased.