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!! _______________________________________________ Evince-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evince-list
