Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Speed up page turning on big cre documents #3740
Page turning, menu opening, ... everything actually!
In crengine, at the end of each
We don't need any of that, as we manage our highlights and bookmarks ourselves, and we draw them ourselves over the clean page drawn by crengine.
But it's just as good as doing it simply with a method call, a bit later in the opening process, as this PR does.
On the emulator, the real rendering work takes like 10ms.
(about the first commit)
When I run the TOC unit test in isolation it passes, but as part of the whole it does not. But it's not the kind of test that should care. Page numbers could be different if a previous test zoomed the document or some such, but the number of TOC elements can't change.
The other tests seem to fail convincingly in isolation.
Using the program I see no obvious issues.
I added this to one of the failing tests:
The results are… there's no difference in the base TOC. The only logical conclusion would be that there's something the matter with readertoc itself. I don't really have time to investigate exactly how it fails atm. The output of
"Good" & "Bad" readerui.document:getToc()
Thanks for the tests.
It makes sense crengine-code wise to re-enable this internal history when resizing, as somewhere in the resize workflow, there is a
We already have it implemented fully on koreader side.
But there is indeed internal support in crengine for bookmarks and history (see https://github.com/koreader/crengine/blob/master/crengine/include/hist.h https://github.com/koreader/crengine/blob/master/crengine/src/hist.cpp). I couldn't figure out where this history records file would be saved to ! I guess they would be used by coolreader UI code, it would fetch the history records as a XML stream and do the saving and feeding back from elsewhere.
But we don't use them at all from koreader - and there are just a few hooks into this in the crengine code we use. This PR just disable the most costly stuff - and my test commits from this morning showed we need to keep a few hooks enabled - the rest shouldn't hurt.
Alright, go ahead.…
On Mar 12, 2018 20:42, "poire-z" ***@***.***> wrote: It's still working fine, so I guess we can merge it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3740 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMYBQBiO9cxLh2R7a3XMvr9uYcfMFByks5tds-wgaJpZM4Sl3in> .