Page turning latency benchmarks?

[Hyphen-ated]

Originally Posted by Renate

More edit: I made a USB device that I can set to repeatedly do page downs at a specific rate.
At 3 page turns/second it seems that it wasn't running smoothly.
At 2 page turns/second it ran smoothly.
Wow, I just ran through Moby Dick, but my comprehension was poor.

That's awesome! It's sidestepping some important elements of what I care about testing, though. You're removing the need for the reader software to detect input from the user, right, which could be a significant source of delay? And also, my own testing shows that for my device there is a HUGE decrease of latency when mashing "next page" as fast as possible. I'm guessing the reader might go into some kind of mini-sleep mode when it has been sitting on the same page for a few seconds.

[pazos]

Originally Posted by Hyphen-ated

Nah. My comparison is with reading text on my computer, which has something like 0.05s or less page turn delay for an epub.


Oh really! I looked at Koreader's list of features in the past and saw no claims about improved performance, which I figured would be a big deal they would want to brag about. I'll have to check it out.

It really depends on system EPD controller as we don't talk to eink directly on most devices. On devices that we race against system controller we win by a huge margin so we introduce delays to let the system driver finish its job before us to prevent artifacts: https://github.com/koreader/koreader...id.lua#L37-L39

That says little about our own loop and a lot about how these devices weren't designed for fast page turns.

Even on serious devices where we talk to the EPD using ioctls there's nothing to brag about it. Requesting a refresh takes a fixed amount of time (which varies depending on the waveform, the mode, the region of the screen to refresh, what's actually on screen...). If we're fast or not depends on what happens before the ioctl is triggered.

[Hyphen-ated]

Originally Posted by pazos

Even on serious devices where we talk to the EPD using ioctls there's nothing to brag about it.

Supposing it reduces the latency on some devices from 2s to 1s, that would be extremely bragworthy

[Renate]

Originally Posted by Hyphen-ated

It's sidestepping some important elements of what I care about testing, though.

Well, the command from hardware button, finger tap, finger swipe, console command to key injector, USB key or Bluetooth key really only takes a few milliseconds, which is small compared to what we're looking for.
The ADB input command is slow and not worthy of our consideration because it spins up a Java for the trivial task of injecting an input.
I have wired up stick-on foil and a diode pair and driver to simulate a capacitive finger touch before also. (I even still found it on my desk.)

Most (all?) ereader apps load/compose/whatever the next page while you are reading the current page.
That is a reason why repetitive page flipping could run into limits and actually be slower.
For a modern device to "wake up" by goosing the CPU governor doesn't take any time.

The next time I have to pop open my Poke3 I'll take some measurements like the Glow3, 4 above.

[Hyphen-ated]

Originally Posted by Renate

Well, the command from hardware button, finger tap, finger swipe, console command to key injector, USB key or Bluetooth key really only takes a few milliseconds

How do you know that this is the case for all devices? It SHOULD only take a few milliseconds, but nothing stops the software on any reader from being badly written and wasting an arbitrarily large amount of time here. I want to test real performance in real conditions and make as few assumptions as possible, ya feel me?

That is a reason why repetitive page flipping could run into limits and actually be slower.

Oh interesting, the opposite of what I've experienced. I'll take some video of how fast flipping speeds up for me.

[Hyphen-ated]

I did some tests with the Moby Dick epub.
Turning pages normally.
Average latency: 1.57s


Turning pages ASAP after the previous page turn.
Average latency: 0.80s


I realized a confounding factor: how long I keep my finger touching the screen makes a difference. So I did another test where I wait a longer amount of time between turns, but I keep the duration of my press as short as possible. I wasn't strictly controlling this in my previous tests. It might be best to measure from finger-up instead of finger-down in the future, but that makes it slightly harder to see the exact right frame. On the other hand, I don't want to have to fling my finger off the screen like this when actually reading -- measuring from when the finger hits the screen is the thing I truly care about. If there's a reader that doesn't add the duration of the finger press to the turn latency, that would be a relevant fact I'd want to know about it.
Average latency: 1.23s


So after eliminating the finger touch length discrepancy, going for another page turn as quickly as possible after the previous page turn reduces the delay for me by about 35%

[hobnail]

Originally Posted by Renate

Most (all?) ereader apps load/compose/whatever the next page while you are reading the current page.
That is a reason why repetitive page flipping could run into limits and actually be slower.
For a modern device to "wake up" by goosing the CPU governor doesn't take any time.

On the elipsa I've noticed a definite difference in time when going from the last page of a chapter to first page of the next chapter; slower but not aggravatingly so, just noticeable. Maybe it only keeps one chapter at a time in memory?

[Hyphen-ated]

Wow, KOReader rules.
Average latency: 0.58s (omitting the refreshes and the one missed touch)


That's more than twice as fast as the built-in reading software. The latency is basically tolerable now. Amazing. Now I just need to figure out how to make the rest of its UI behave in a way that I can stand.

[Renate]

Until you lift your finger, the device can't tell if you are going to swipe instead.
Yes, you could make areas of the screen work on touch down and forsake swipe there.

I have made tests with (electrical) touch, key injector, USB, BT and haven't noticed any difference.
On the oscilloscope you can easily see the amount of time thinking about an update and doing an update.

It looks like the stock software on the Kobo Aura HD doesn't prepare the next page in the background.

Another benchmark to check would be to read a bunch of pages forward, then go one page backwards and see if that is slower.
(I often flip a page back to check something.)

[JSWolf]

Originally Posted by Hyphen-ated

I did some tests with the Moby Dick epub.
Turning pages normally.
Average latency: 1.57s

Your Aura HD is really slow. I tested my H2O (1st gen) against your Aura HD using your video. When I tapped at the same time or slightly after, my page turned faster and I have more text on screen and I have hyphenation on.

[Renate]

Another test to make would be to make the text as small as it goes. That would make the processing more complex but shouldn't make the actual updating any slower.
Then compare that with making the text enormous.

Edit: Hmm, on my reader the actual compose takes 125 mS irrespective of the font size being tiny or humongous.
Note: This is not a contributor to page turn times because it's already done before your finger hits the screen.

For readers that do an actual graphical compose in the background there should be zero difference.

[DNSB]

Originally Posted by hobnail

On the elipsa I've noticed a definite difference in time when going from the last page of a chapter to first page of the next chapter; slower but not aggravatingly so, just noticeable. Maybe it only keeps one chapter at a time in memory?

Is it possible that you are set to do the full page refresh per chapter?

[Hyphen-ated]

Originally Posted by Renate

Until you lift your finger, the device can't tell if you are going to swipe instead.
Yes, you could make areas of the screen work on touch down and forsake swipe there.

You could also have it go "I have detected the beginning of a touch. This might end up being a tap or a swipe, so I'll speculatively start any work necessary to respond as quickly as possible once I know which it is"

I have made tests with (electrical) touch, key injector, USB, BT and haven't noticed any difference.
On the oscilloscope you can easily see the amount of time thinking about an update and doing an update.

How many different devices have you tested with an oscilloscope in this way? Surely not all existing ereaders.

[Hyphen-ated]

Originally Posted by JSWolf

Your Aura HD is really slow. I tested my H2O (1st gen) against your Aura HD using your video.When I tapped at the same time or slightly after, my page turned faster and I have more text on screen.

Unfortunately, "my page turned faster" is much less useful than actual numbers for anyone who wants to make purchasing decisions informed by page turn speed

[j.p.s]

Originally Posted by hobnail

On the elipsa I've noticed a definite difference in time when going from the last page of a chapter to first page of the next chapter; slower but not aggravatingly so, just noticeable. Maybe it only keeps one chapter at a time in memory?

Many epubs are generated with 1 *html file per chapter.