KOReader doesn't open large, complex ebooks?

[NiLuJe]

@poire-z is going to be away for a few days, but he mentioned that'll he'll be looking into it when he gets back .

[Marinolino]

I've aborted it after unsuccessful 35 minutes, by restarting Kobo.

[NiLuJe]

Yeah, if it takes 10 minutes on a souped up Skylake, I really really don't encourage anyone to try on a measly i.MX6 ;p.

[SbAgOoTs]

Originally Posted by NiLuJe

@poire-z is going to be away for a few days, but he mentioned that'll he'll be looking into it when he gets back .

OK, thanks.
I hope my warning helps to improve KOReader even more, making it able to open any epub...

[Frenzie]

And it's hardly like my Haswell i7-4790 is a slowpoke either. Most of the discrepancy between my numbers and @NiLuJe's should be because I was using a debug build. If I'm not mistaken mine should be some 10-20% slower at most, possibly slightly higher under specific workloads.

I'd give it an absolute minimum of 100 minutes on an actual H2O/One given the numbers we posted, more likely easily twice that. (And if you run into heat-based throttling… who knows.) Hardly worth attempting unless you really want to verify whether it'll run out of memory along the way.

$ inxi
CPU: Quad Core Intel Core i7-4790 (-MT MCP-) speed/min/max: 1038/800/4000 MHz Kernel: 4.19.0-5-amd64 x86_64 Up: 1h 48m 
Mem: 5603.5/32112.8 MiB (17.4%) Storage: 3.87 TiB (54.4% used) Procs: 295 Shell: bash 5.0.3 inxi: 3.0.32

[SbAgOoTs]

Originally Posted by NiLuJe

@poire-z is going to be away for a few days, but he mentioned that'll he'll be looking into it when he gets back .

Any news?
With August version the result is the same unfortunately...

[SbAgOoTs]

Originally Posted by NiLuJe

@poire-z is going to be away for a few days, but he mentioned that'll he'll be looking into it when he gets back .

No good news from September release either...

[SbAgOoTs]

Originally Posted by NiLuJe

@poire-z is going to be away for a few days, but he mentioned that'll he'll be looking into it when he gets back .

No luck with November release either...
Why (talking about Android) apps like Moon+Reader or ReadEra can do it very easily and my beloved Koreader can't?

[NiLuJe]

@SbAgOoTs: Chunked decoding vs. full papyrus scroll approach .

The downside being a large upfront cost, with the upside being a much smaller performance impact at runtime, as long as no layout changes are requested.

[pkbo]

Originally Posted by SbAgOoTs

Why (talking about Android) apps like Moon+Reader or ReadEra can do it very easily and my beloved Koreader can't?

ReadEra uses crengine to render epubs. Are you sure it can open some large epub that Koreader can't or you are talking about other format?

[SbAgOoTs]

Yes, even if the first run needs some minutes, ReadEra succeded in opening exactly the same test epub, whereas Moon+Reader is close to be immediate.

[Frenzie]

I wouldn't call anything exceeding five seconds or so very easily, but that aside.

Are you talking about KOReader on the same device as ReadEra?

[SbAgOoTs]

You are totally right. My bad choice of words.
Anyway, yes: same file, same device.

[pkbo]

Originally Posted by SbAgOoTs

the Italian one: https://download-a.akamaihd.net/file.../f3/nwt_I.epub.

I've checked this file. It has about 4000 xhtml files, they are rather small, most are less 10Kb but they include default.css which is about 126Kb with lots of rules like this:

html,body,div,span,applet,object,iframe,h1,.st,h2,.ss,h3,h4,h5,h6,p,.sb,blockquote,pre,a,abbr,acronym,address,big,cite,code,del,dfn,em,img,ins,kbd,q,s,samp,small,strike,strong,sub,sup,tt,var,b,u,i,center,dt,dd,li,fieldset,form,label,legend,table,caption,tbody,tfoot,thead,tr,th,td,article,aside,canvas,details,embed,figure,figcaption,footer,header,hgroup,menu,nav,output,ruby,section,summary,time,mark,audio,video{text-indent:0;margin:0;padding:0;border:0}

I think disabling internal styles should greatly improve loading speed.

[Frenzie]

It also includes rules like this:

div.east_right{width:40% !important;clear:both;float:right;margin-top:0em;margin-bottom:1em;display:inline-block}

That's important because KOReader supports floats, while other CREngine implementations don't yet afaik.

Besides that KOReader defaults to proper kerning, which is slower, it implements RTL, which may be relevant if there's Hebrew in the document, and it more correctly CSS selectors with + (I'm not sure if that makes it any slower otoh but there are an awful lot of + selectors in there which isn't exactly recommended for document performance).

On a stress test like this, it could unearth some logical flaw in the support for an extra CSS selector.

Anyway, as stated disabling various features would greatly improve the speed. Font kerning possibly good, but definitely not best. Render mode, probably best to go with legacy or flat. And indeed one might consider turning off embedded styles completely. (Basically either make those the default by long pressing or pre-make an SDR.)

I forget, was that file ever reduced to a test case?