Good handling of high-res scans (avoiding thrashing)

[Alan Jenkins <aj504 student cs york ac uk>]

I recently received 8 pages of scans at 4961x7096, compressed using the 
greyscale variant of JPEG.  While compressed to ~3M each, viewing them on my 
256M ram computer was rather interesting.  Many of the applications I tried 
left my HD led on as they tried to uncompress rather more than was good for 
them.  With one page open at a time it was bearable, but when I opened 
several at a time it got out of control.  A secondary issue was that these 
scans were sent as landscape, when the writing was portrait.

I would suggest that this is an interesting use case for people who use scans 
casually, and therefore end up with unwieldy image files because it was 
easier to use a very high resolution than take time to find the most suitable 
resolution.

This is all rather subjective, but I found the best solution was to wrap the 
JPEGs in PDF (as opposed to the usual JFIF for .jpeg/.jpg files) using sam2p 
and use evince.  <insert praise for evince here>.  Acrobat reader on linux 
was less useable, partly because scrolling was rather jerky <more praise unto 
evince>.

sam2p took a couple of seconds, and left the filesizes virtually the same, so 
I'm confident the image data was exactly the same. evince appears to have a 
relatively undocumented feature of opening JFIFs directly, but showed a 
significant difference in performance (read thrashing).

I'm not going to attach 2M image files but this should all be reproducable 
simply by creating large images.  It would probably be easier to see problems 
with nonblank images, e.g. to test scrolling, and to make sure that some bug 
in evince isn't causing the page to be drawn as blank anyway (I've experience 
such a problem in evince only, many times, seemingly triggered by scrolling).

My queries are whether it would be possible to
a) get evince to display the JFIFs with the same performance as the PDFs by 
switching backends (if thats the problem) or generalizing smarts in evince 
(if thats what makes the PDF viewing bearable).
b) improve the performance of rotation by performing it as late as possible in 
the rendering chain, after scaling.  I don't know whether there are embedded 
orientation-sensitive user interface elements e.g. in PDF forms which would 
obstruct this.

I'm afraid I'm unlikely to have the interest to follow this up, apart from 
documenting it in more detail.  If requested I might get as far as writing a 
test case to create blank images which are large with respect to the RAM 
available on any given computer.