Optimized rendering for big files

Hi all,

Attached is a patch that integrates my work from last GSoC into the
current trunk. It implements a new algorithm for finding which pages
are on screen and drawing them: instead of starting at the beginning
of the doc and iterating through every single page, the new code
selects an optimized starting page (currently hardwired to wherever
the cursor is, which is still a much better guess than the beginning)
and then goes up and down the doc from that point looking for which
pages to render until it exits the viewport.

Also, the rendering itself has been greatly simplified: the old
approach was to split the screen into many different rectangles
representing the pages and the spaces between them, but now we just
redraw the background and lay the pages on top each time we need to
redraw an entire page. I don't think there's a big performance hit,
maybe performance has even improved. It shouldn't matter at all once
we get double buffering.

Finally, finding pages to render has been separated from the loop to
actually draw them, which should make putting the rendering process
into a background thread easier later on.

Why you should care: very large files are now practical to edit, as
long as breakSection is not called (i.e., no pressing enter or
deleting lines).

A note on having taken so long to integrate into trunk. My original
intention was to remove all assumptions about page sizes to allow for
variable page size and eventually arbitrary page positions. This
broke many things and eventually I realized that the assumptions are
just too deeply embedded. So, I've abandoned trying to change them
and instead have focused purely on performance. Once my doctoral
program started, time became scarce =). I hope to build on this work
for this summer's GSoC, ideally by moving breakSection into a
background thread.

-Ersin

P.S.: This patch also fixes that annoying bug with the lower right
corner of the page's drop shadow in page view.

-- 
Ersin Y. Akinci -- ersinakinci.com
What Digital Revolution? -- www.whatdigitalrevolution.com
Thinking critically about digital worlds.