Mobileread
KOReader is blazing fast
#11  heyman 05-26-2019, 01:01 PM
Quote Frenzie
Nickel could be faster at parsing an EPUB
Koreader should have faster page turning on Kobo right? In normal reading
Reply 

#12  Frenzie 05-26-2019, 02:17 PM
I said could, not is. I've got an EPUB here of the larger persuasion that takes ~10 s to load in Nickel and ~5-6 s in KOReader/crengine, which is the general trend in my experience.

But indeed, Nickel is surprisingly slow to turn pages. It seems to take a small eternity, although tbh I hadn't really noticed in normal use. I wonder if maybe it's an artificial delay, e.g. to support double taps, to prevent accidental double page turns, or to avoid potentially ugly looking overlapping refreshes?
Reply 

#13  NiLuJe 05-26-2019, 02:46 PM
The ePub renderer is mightily awful as far as performance goes, especially on older FW versions.

The KePub renderer, on the other hand, has always been pretty decent, although still a tiny bit slower than a Kindle, which is especially noticeable if you've recently used one. Still perfectly usable, though (unlike the ePub renderer, IMHO, which was probably colored by the fact that I did come from a Kindle ;p).

With the recent tweaks (i.e., >= 2019.05), in KOReader, as long as you're staying in the default Portrait orientation, we're pretty much trouncing everything out there in terms of page turn speed, though, especially if you have a device with physical buttons, because you bypass a good chunk of the input loop/gesture detection/delay thingy that way.

Sidebar: turns out storage performance is also pretty key to some specific use-cases. For instance, I'd always found dictionary performance to be pretty meh on my H2O, while it's basically instant on my Forma.

The difference? A real eMMC chip on the Forma vs. the insane internal SD card design on the H2O. It's sure nice on the hackability front, but, man, is it awful in terms of performance.
Reply 

#14  Frenzie 05-26-2019, 02:56 PM
Touch/gesture detection generally doesn't really delay, unless there are a lot of links in the document or on the page. (In which case technically it's link detection that delays, not gesture detection.)

Since Nickel easily takes 10 times as long to turn a page if not more, I guess that means Nickel would also be significantly worse for battery life?
Reply 

#15  NiLuJe 05-26-2019, 02:59 PM
Yup! There's probably a mainly fairly psychological effect of the button feeling clicky and stuff showing up on screen straight away that just feels nicer ;p.

Note that the H2O is a fairly terrible benchmark, because it has weird-ass power management quirks that make its frequency scaling behave pretty erratically. Meaning it can be hard to actually get it to stick to the full clock speed properly. It tends to get stuck at lower clock speeds for far too long for no good reason.

For instance, mine is fairly consistent on a fresh, cold boot, and then starts to go wonky at the first sleep cycle. Although, "fairly consistent" might be stretching it, because it tends to stick the other way around after a cold boot (meaning stick to the highest clock speed even when idle).
Reply 

#16  Frenzie 05-26-2019, 03:01 PM
Speaking of delay, I just came across this today:

https://blog.wooting.nl/what-influences-keyboard-speed/
Reply 

#17  Frenzie 05-26-2019, 03:08 PM
Quote NiLuJe
The difference? A real eMMC chip on the Forma vs. the insane internal SD card design on the H2O. It's sure nice on the hackability front, but, man, is it awful in terms of performance.
Even after the first load? I'd expect it to hang around in memory.

Quote NiLuJe
For instance, mine is fairly consistent on a fresh, cold boot, and then starts to go wonky at the first sleep cycle. Although, "fairly consistent" might be stretching it, because it tends to stick the other way around after a cold boot (meaning stick to the highest clock speed even when idle).
Yeah, occasionally I notice oddly slow page turns where I can only assume it's the scheduler underperforming. But oddly slow as in it takes 100 ms instead of 20 ms (or whatever), so still a lot faster than Nickel. :P
Reply 

#18  heyman 05-27-2019, 12:06 AM
@Frenzie @NiLuJe

please correct me if I say something wrong.

I still believe koreader running on simple linux (kobo, kindle) could be faster (like faster page turning) than android version. Because android is a over-big, over-messy architecture. Android itself is an "app" running above the linux (kernel), and we run our apk on the android (java), android is actually a VM, this casuses more delay than anything else.
Reply 

#19  Frenzie 05-27-2019, 06:31 AM
Quote heyman
I still believe koreader running on simple linux (kobo, kindle) could be faster (like faster page turning) than android version. Because android is a over-big, over-messy architecture. Android itself is an "app" running above the linux (kernel), and we run our apk on the android (java), android is actually a VM, this casuses more delay than anything else.
I don't think that's necessarily true provided you've got enough RAM, but Android doesn't really have much to do with anything. Nickel is the same principle as KOReader (or coolreader or Plato). Just a fullscreen app running on embedded Linux.
Reply 

#20  pazos 05-27-2019, 07:18 AM
Quote heyman
@Frenzie @NiLuJe

please correct me if I say something wrong.

I still believe koreader running on simple linux (kobo, kindle) could be faster (like faster page turning) than android version. Because android is a over-big, over-messy architecture. Android itself is an "app" running above the linux (kernel), and we run our apk on the android (java), android is actually a VM, this casuses more delay than anything else.
No, android is not an "app". It is a framework based on multiple services/daemons running.
No, the Dalvik/Art virtual machines don't cause any noticeable delay.
Reply 

 « First  « Prev Next »  Last »  (2/3)
Today's Posts | Search this Thread | Login | Register