Evince threading update

[Jonathan Blandford <jrb redhat com>]

Hey guys,

I thought I'd give a quick update on the 'evince-thread' branch to let
people know what the current status is.  I rewrote the rendering and
threading code again this weekend.  It's not quite done, as I need to
finish writing ev_pixbuf_cache_update_range() in ev-pixbuf-cache.c.
However, I now know how to do that nicely.  When that's done, the new
rendering code will have all the threading features needed to start
thinking about merging it back to HEAD.

I'm pretty happy with how it's performing.  There are some things that
could be improved, but it's a vast improvement over the current code in
terms of responsiveness.  Additionally, it's now really trivial to write
the dual-page mode or to add a continuous view mode[1].  I really want to
write these two modes, but I think we're better off merging this back to
HEAD before starting that.

COMMENTS ON THE NEW SYSTEM
--------------------------

We now have an entirely new rendering model, which involves rendering to
a GdkPixbuf instead of passing expose events to the backend.  I was
trying to keeping the server-side rendering working as it would make
more sense for the ghostscript backend, but I don't think it is doable
in the short term.  There's no good server-side pixmap scaling code, and
having one code path is really nice.  We can add a pixmap-based
optimization in the future, but for now lets just call
gdk_pixbuf_get_from_drawable() and get it working.

As a side-effect of this new approach, all the backends but pdf are
currently broken.  I'm going to suggest that we fix the .ps backend and
drop the pixbuf backend for now.  The pixbuf backend should be really
easy to write, but it still doesn't make sense w/o collections and
multi-page support.  Eog will do a better job than we will, too.

There are some inherent scaling issues in the new design.  If you zoom
in a lot, we're passing giant GdkPixbuf's back and forth.  It's no
different from the current code anyway, as xpdf allocated a giant Pixmap
to draw to, but it still sucks.  I have some ideas on how to do a better
job, but we'll implement it later.  It's a really neat problem if anyone
is interested in tackling it.[2]

RAMIFICATIONS OF THE NEW SYSTEM
-------------------------------

The biggest change with the new system is that we no longer can access
the EvDocument directly.  It is now protected by a single lock
(EV_DOC_MUTEX) that all callers must have prior to making a call to it.
Currently, the grabbing of this lock is a bit of a mess -- it's spread
out between ev-document.c and ev-job-queue.  This was done to get
something going quickly.  I will remove all the locks from ev-document.c
shortly and sanitize the calling to make it more obvious how to use the
mutex.

The implication of this is that _ANY_ call to ev_document could take
several seconds to complete, and thus should not be done from the main
thread unless necessary.  All the rendering jobs (both thumbnails and
main pages) are pushed out to the helper thread, and we're going to have
to do something similar with other features.

LEFT TO BE IMPLEMENTED
----------------------

Currently, only the rendering (thumbnails and display) is threaded in
the branch.  Left to be done is:

 * indexing
 * links
 * selection
 * search
 * saving
 * printing

It sounds like a lot, but I don't think it's actually all that bad. I'll
go through each item one by one:

We can implement saving and printing using the global lock for the
initial release without interfering too much with the user experience
(users expect those operations to be 'slower' than resizing/scrolling.)

I am pretty sure that I can work the indexing into the current job queue
easily.  I am really surprised that it's as slow as it is though (it's
pretty instantaneous in acroread) so we might give a look at poppler to
see why it's so slow.

Links also seem doable.  We can return a list of GdkRectangle/EvLink
pairs with ev_document_get_pixbuf(), and use that in motion events.  It
should be fast to do, too.  It will require a bit of work, but is
definitely possible.

For selection, i'm not a giant fan of the current interface anyway, as
the square selection region is weird.  We could add it to the queue
system on mouse_up, under the expectation that you don't call C-c
immediately, or go sync here.  I wouldn't complain if we disabled it
entirely until we got real text-selection in poppler, as using the mouse
to grab/move the page seems like a more useful feature for now.  I'm
don't have a strong opinion about it, either way.

Which leaves us...

SEARCH AND POPPLER CHANGES
--------------------------

For search to work, I think we're going to need to make some changes to
poppler.  I don't think we can realistically implement search in the
current queue system and have it be responsive.  I think the best
approach here is to allow poppler itself to be thread aware, and add
another thread just to handle the search code.  I suspect that we're
going to need something similar for the selection code, though I'm not
sure.  

Basically, we want to create different renderers in different threads,
and keep the bulk of the pdf structure read-only.  Kristian and I have
been discussing making some changes to the poppler API to allow this,
but it's a little bit scary.  If we can't do this, we probably want to
fall back to the synchronous code though that'll be pretty bad.  This is
definitely going to have to be something we figure out soon, though.

[ One other side effect of doing this in a separate thread is that it
  makes implementing search in a non-pdf backend that much harder to do.
  It's something to think about, anyway... ]

OTHER THINGS
------------

Next/prev/goto page is currently broken in the branch.  It's easy to
fix, and will be done shortly.

One other small feature regression is that we no longer do the visible
area for thumbnails right away.  That feature was pretty cool when we
had it and it's a shame that its gone.  This is some fun code that needs
writing, and there is some framework for handling it already in place.
I haven't gotten around to doing it yet, but if anyone wants to tackle
it, that would be great!

Additionally, the postscript backend needs moving to the new system.  I
can give further details if someone wants to pick this up.

CONCLUSION
----------

I'm going to keep pushing forward on cleaning up the thread queue and
sanitizing the locking in the near future.  I'm also going to look at
indexing.  I don't know many of these features we want to get working
prior to merge, but I'd really like to get this new code tested ASAP.

Thanks,
-Jonathan

[1] In fact, I might go ahead and do it anyway.  We should be able to
experiment with 'alternative' layouts too, such as horizontal-only.

[2] It really is a fun problem!  Ask me for details if you want to
tackle it!!