Re: Good handling of high-res scans (avoiding thrashing)

["Nickolay V. Shmyrev" <nshmyrev yandex ru>]

В Пнд, 29/05/2006 в 15:26 +0100, Alan Jenkins пишет:
> 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.

Dear Alan

Thanks for such detailed description of your use case. You are correct,
high memory consumption is the most important evince problem recently.
We are trying to work on it but that will require substantial changes.
And we must keep balance between speed and memory usage that makes it
hard to accomplish that task. 

It's funny that even now when performance of modern systems is perfect
and memory is very huge developers still should care about memory and
speed :)

Actually I was planning to make our page cache behave more intelligently
by bypassing the cache for large images. But sadly it won't be perfect
solution anyhow. Probably we'll move to cairo (good old idea of pixmaps
and server rendering in modern presentation, also remember PostScript-
based desktop in Solaris) some day instead of pixbuf rendering. But now
the problem of big documents is still open.