GNOME Bugzilla – Bug 343542
block new instances while loading
Last modified: 2007-01-24 18:20:41 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/evince/+bug/45957 "... If Evince blocks awaiting Internet download of a PDF then it is not possible to view any local file with Evince. All new instances of evince go into the same "Loading document. Please wait." mode. I guess Evince is not properly multi-threading. ... This does still happen with the newest version in Dapper. Whilst viewing a pdf over ftp using evince, attempts to view pdfs on the local filesystem sit with the "Loading..." text. It no only blocks during downloading, but whilst the "Authentication Required" box is shown when viewing a pdf on an ftp site too. reproduce thus: evince ftp://www.tug.org//tex-archive/dviware/dvipdfm/dvipdfm.pdf & evince ~/test.pdf "
Confirm, that is quite deep bug in evince design. The event queue can run only one task of single type in a moment. For example if it searches for a word all other searches will block.
Created attachment 71399 [details] [review] Patch Here is a patch for this problem. Now every job runs on its own thread, so several tasks can be carried out in parallel. It makes evince faster since pages are rendered in parallel. Xfer is async now for remote uris, because auth dialog is modal and blocks any other document too. I'm not sure whether it's a good idea to commit this change now (at the end of the release cycle) since it's a change in the design. I've done several tests and it seems to work, but threads have very often unpredictable behaviors for different users, so it has to be tested a lot.
I've noticed that this approach has some problems. So, we definitively shouldn't commit this in this cycle. I'll try to fix such problems since I think it's worth to use one thread per job.
Created attachment 71543 [details] [review] Updated patch I was wrong, tasks in fact are never carried out in parallel, because of global document mutex. When a thread is running, the others are waiting to acquire the lock. Anyway, this approach is faster than having a single thread. The problem is that is possible to have many threads rendering pages that we don't really need, for example when the window is resized in width fit mode. This patch fixes this problem by making jobs cancellable. In addition, it uses one mutex for each document instead of having a unique global mutex. We don't want to wait for jobs of other documents, no?
Finally, I've fixed it in an easier way, so my previous patch doesn't make sense anymore.