loading flow delay for every page

Bug #1658578 reported by M.W. Stanczak
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
calibre
Fix Released
Undecided
Unassigned

Bug Description

PC environment: Windows 7 Ultimate 64-bit with 12Gb RAM in system
calibre version 2.72 experiences the normal "loading flow" delay once when initially viewing an epub, and subsequent page links load immediately. But calibre version 2.77 experiences this "loading flow" delay with each and every page.
With a small epub, the delay may be acceptable, but with the epub I am using (33,000 xhtml text files, 255,000 pages of text, over one million hyperlinks; no graphics other than the cover), this delay causes calibre to be non-functional. Perhaps a caching function algorithm was changed?
I can send the file for your testing, if needed (it is a reference dictionary, 200Mb compressed), and I am willing to assist with debugging in any way you may request.

Revision history for this message
Kovid Goyal (kovid) wrote : Re: calibre bug 1658578

Loading flow happens whenever the internal HTML file being displayed is
changed, the new HTML file has to be rendered and laid out. That remains
the same in all versions of the viewer. If you are saying that the
amount of time taken for each individual loading flow has increased,
then it is likely because of a change to how the html is loaded which is
necessary for security reasons -- nothing I can do to fix that. Although
I have to say that I can see no increase in time for each loading flow
(it remains imperceptible) on, for example, War and Peace.

Revision history for this message
M.W. Stanczak (willie055) wrote : RE: [Bug 1658578] Re: calibre bug 1658578

So, are you saying that you have coded in a change for loading the html due to security reasons in calibre version 2.77 that was not coded into version 2.72? Version 2.72 is lightning fast when changing pages; 2.77 is not.
Can I send you a link to download the epub I am using (via WeTransfer)?
You can test an abridged version that also exhibits the behavior I am describing, downloaded from Smashwords:

https://www.smashwords.com/books/view/682810

But the unabridged file is ten times larger, and much slower.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Kovid Goyal
Sent: Monday, January 23, 2017 2:32 PM
To: <email address hidden>
Subject: [Bug 1658578] Re: calibre bug 1658578

Loading flow happens whenever the internal HTML file being displayed is changed, the new HTML file has to be rendered and laid out. That remains the same in all versions of the viewer. If you are saying that the amount of time taken for each individual loading flow has increased, then it is likely because of a change to how the html is loaded which is necessary for security reasons -- nothing I can do to fix that. Although I have to say that I can see no increase in time for each loading flow (it remains imperceptible) on, for example, War and Peace.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1658578

Title:
  loading flow delay for every page

Status in calibre:
  New

Bug description:
  PC environment: Windows 7 Ultimate 64-bit with 12Gb RAM in system
  calibre version 2.72 experiences the normal "loading flow" delay once when initially viewing an epub, and subsequent page links load immediately. But calibre version 2.77 experiences this "loading flow" delay with each and every page.
  With a small epub, the delay may be acceptable, but with the epub I am using (33,000 xhtml text files, 255,000 pages of text, over one million hyperlinks; no graphics other than the cover), this delay causes calibre to be non-functional. Perhaps a caching function algorithm was changed?
  I can send the file for your testing, if needed (it is a reference dictionary, 200Mb compressed), and I am willing to assist with debugging in any way you may request.

To manage notifications about this bug go to:
https://bugs.launchpad.net/calibre/+bug/1658578/+subscriptions

Revision history for this message
Kovid Goyal (kovid) wrote : Re: calibre bug 1658578

You are welcome to send the file.

Revision history for this message
Kovid Goyal (kovid) wrote :

No need, I took a look at the Smashwords book and it has nothing to do
with the amount of text and everything to do with the 8MB font file that
is embedded. It's likely that the change is causing WebKit to
reload/reparse that font file on every HTML file change -- I dont know
if that is possible to fix, it will need investigation.

Revision history for this message
M.W. Stanczak (willie055) wrote : RE: [Bug 1658578] Re: calibre bug 1658578

Thank you for your support. You should receive an email to this address directly from WeTransfer after about 30 minutes. The file is uploading now.
Sincerely,
MWS

Revision history for this message
M.W. Stanczak (willie055) wrote :

I am confused because the calibre versions behave differently with the same file, so I have assumed that something is different within calibre (and not other parts). Is that unreasonable?
Anyway, my prior email indicates the larger file will be available for your testing if you need it. If not, simply ignore the email of course. The larger file has three fonts embedded, and it is much slower. I cannot remove the fonts, since they are critical for understanding the publication content. I will continue trying newer versions of calibre as you release them, but for now I must stay with 2.72 for my development of this publication.

To manage notifications about this bug go to:
https://bugs.launchpad.net/calibre/+bug/1658578/+subscriptions

Revision history for this message
Kovid Goyal (kovid) wrote : Fixed in master

Fixed in branch master. The fix will be in the next release. calibre is usually released every Friday.

 status fixreleased

Changed in calibre:
status: New → Fix Released
Revision history for this message
M.W. Stanczak (willie055) wrote :

New version functioning very well. Thank you, Kovid.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.