Comment 0 for bug 1774884

Attached is a pretty good example.

While most books are pretty fast, this might indicate a general problem with html rendering that makes file switches slower than it needs to be even for those books where it's acceptably fast.

Navigating to the beginning of chapter 2 on my main computer (3.25, arch linux) takes about 3 minutes stuck on "loading flow".

Also tested in debian (3.24.2, debian unstable) on an older, slower computer, and it took closer to 10 minutes. The difference is probably entirely due to the cpu though (it's an early quad-core kentsfield), I don't think debian is broken in some way that Arch isn't.

In windows 10 (3.25), rendering lag switching to chapter 2 is not bad, about 1-2 seconds.

The html files for both parts of chapter 2 are small <200kb each, and while they embed a fair number of equation images, it's nothing absurd (about 500 images total in the ebook). There are a handful of embedded fonts but they're 200-400kb, and fairly standard (dejavu and times).

I cut out the rest of the chapters to make the file size more manageable, since chapter 2 was a good example.

Perhaps it has something to do with font rendering (unicode fonts?), or lots of tiny images, or unusual css, or some combination. I tried extracting the epub contents, viewing ch2 or ch2a html files in a real web browser (chrome, and even konqueror), and it's just about instant, not even the 1-2 second delay seen in ebook-viewer on windows.

There was a bug over a year ago related to loading of large fonts. I don't know whether that's related, but that one was marked fixed. https://bugs.launchpad.net/calibre/+bug/1658578