Ticket #49 (assigned defect)

Opened 2 years ago

Last modified 2 years ago

well structured web site, i wish all of them would be like that

Reported by: anonymous Owned by: jordi
Priority: major Version: 0.1.5
Keywords: Cc:

Description

I have a fast computer, but even then it takes sometimes about 4 seconds to go to the next page, I use icewm, I can see the CPU going crazy. This happened on all pdf files I tried.

xpdf does not have this problem, but has another problem, it messes up the doc after a screen resize.

Thanks, seems to be a nice light program.

Change History

Changed 2 years ago by LoneFox

I experimented with the code a bit, and found out that:

  1. PagePter::pageNotAvailable() is called a few million times per page when the "Loading..." text is on the screen. This is the main reason of these performance problems. I don't know exactly what is happening, because adding debug code (printf calls) changes the behavior of the program. Sometimes the delay disappears, while other changes seem to cause an infinite loop.
  2. If I "fix" the first problem by adding some g_usleep in that function, the program usually works fine, but some pages that contain line drawing style graphics render still very slowly. This problem seems to be in poppler and not epdfview.
  3. If I go back one page to quickly check something on the previous page (quite common use case at least for me), the page where I came from is dropped from the cache and then immediately added again. This often triggers problems 1 and 2 when I continue forward before the page is finished rendering.

Changed 2 years ago by jordi

  • status changed from new to assigned

1. True. I use g_idle_add() function to call !PagePter::pageNotAvailable() when the application is idle, which is most of time while loading. Probably I'll change this to call g_timeout_add() instead. The bottleneck probably is that each time the !PagePter::pageNotAvailable() call is made, the application has to create a new page with the 'Loading...' text in it.

2. Poppler is still slow on complex pages, so if the time parameter in g_usleep() is small enough, it shouldn't be any difference. Although I still it's better to use g_timeout_add() to call the function than to block the whole thread each time it's called.

3. Yep, there seems to be a problem with dropping pages from cache that I can't find yet, sorry.

Note: See TracTickets for help on using tickets.