Koreader running on Kobos (all of them, hopefully!)

[xping]

Originally Posted by Ken Maltby

I don't have a mini to compare to, but my AuraHD seems as quick as ever. How is it slow, what is taking longer than it should? Are we talking seconds?
How many?

Luck;
Ken

I don't know why, but with koreader, my aura hd needs 2 o 3 seconds to turn page: I touch the right side of the screen and I have to wait 2 or 3 second to see next page.
If I touch bottom side to call menu, I also have to wait 2 or 3 seconds and so on. it seems that something slows down gesture detection

[Markismus]

Originally Posted by xping

I don't know why, but with koreader, my aura hd needs 2 o 3 seconds to turn page: I touch the right side of the screen and I have to wait 2 or 3 second to see next page.
If I touch bottom side to call menu, I also have to wait 2 or 3 seconds and so on. it seems that something slows down gesture detection

This was the main reason I got an Aura after crashing my Aura HD. I had the same lags. Sometimes they were less annoying, sometimes the annoyance increased.
Ken seems to have another Aura HD, than me. For him suspend works fine, I never got it to work. Maybe there is a difference between the units shipped to USA and to the Netherlands. The black tape on the inside was different, too.

[xping]

Originally Posted by Markismus

This was the main reason I got an Aura after crashing my Aura HD. I had the same lags. Sometimes they were less annoying, sometimes the annoyance increased.
Ken seems to have another Aura HD, than me. For him suspend works fine, I never got it to work. Maybe there is a difference between the units shipped to USA and to the Netherlands. The black tape on the inside was different, too.

do U think aura (new aura?) is less laggy and more reliable? Just thinking to change my HD with "standard" aura....

I couldn't belive that expensive devices like kobos weren't able to reflow pdf text.... (my old prs-t2 did it flawlessy....).... now I have a "top" device wich is laggy.... with problems on suspend mode and so on?

What's about kindles? is it true that there is no text reflow for pdf?

[Markismus]

Originally Posted by xping

do U think aura (new aura?) is less laggy and more reliable? Just thinking to change my HD with "standard" aura....

I couldn't belive that expensive devices like kobos weren't able to reflow pdf text.... (my old prs-t2 did it flawlessy....).... now I have a "top" device wich is laggy.... with problems on suspend mode and so on?

What's about kindles? is it true that there is no text reflow for pdf?

I think that having to draw only half the pixels with the same hardware is showing.
But it took me more than a week to get convinced that I didn't need that beautiful screen, that I could make do with a lesser screen which was faster.

I do not have Kindle. Koreader is there for both, so with both you can reflow a pdf.

[Ken Maltby]

I only had suspend working for a short time with the message timer set to zero, but every attempt since then hasn't worked for me either. My page turns are at a second or less, most at about a half second. I haven't been reading PDFs, so those could be slower.

There has been times when my AuraHD seemed a little "different", but that was as often due to its not working as well as others. On the whole though it seems to work well, in between my messing it up, from time to time.

Luck;
Ken

Perhaps I could make an image of my current setup, and maybe establish if it is a difference in hardware? I have not had a lot of luck with sharing large files though.
Have you guys tried Sergey's Coolreader port, to see if the lag you are seeing is also showing up there?

[Markismus]

Originally Posted by Ken Maltby

My page turns are at a second or less, most at about a half second. I haven't been reading PDFs, so those could be slower.

With the Aura and crengine I can actually blur forward, easily moving 6 pages ahead within a second.
So I suppose for now we can look at it as a difference in perceived lag.

With pdf's I can flip pages back at a reasonable speed, with my Aura HD that would take seconds, up to 10 sometimes---my biggest annoyance. This was of course with large PDF's, usually with reflow, but that's why I use Koreader in the first place.

[Ken Maltby]

Originally Posted by Markismus

With the Aura and crengine I can actually blur forward, easily moving 6 pages ahead within a second.
So I suppose for now we can look at it as a difference in perceived lag.

With pdf's I can flip pages back at a reasonable speed, with my Aura HD that would take seconds, up to 10 sometimes---my biggest annoyance. This was of course with large PDF's, usually with reflow, but that's why I use Koreader in the first place.

I can move fast through the pages as well, but if I am tapping the screen that fast I am not able to time the individual page turns.

I added a couple of different PDFs, including FM 4-22.11 The First Aid Manual, and they do not lag. The PDF page turns may be a little slower than the EPUB, but they are still easily under a second.

Luck;
Ken

[Ken Maltby]

I just tried getting suspend back, and it is working, for now, with these modifications to; "uimanager.lua" changing line 300 from "self:scheduleIn(0.5, function() Device:Suspend() end)" to self:scheduleIn(2, function() Device:Suspend() end)

[as discussed at Github IIRC, 2 works best for the AuraHD]

I also change line 297 from "timeout = 1," to "timeout = 0," so the message is not up to be caught showing when the display is suspended. This lets me "freeze" the page being displayed, without the message. If you want the message displayed while in the suspend mode you may have to increase the timeout until it is up when your device goes into suspend mode.

This is with the v2013.03-696-gc052655 build. Edit: Also 701 build.

One unfortunate side issue, if you go back to nickel (the Kobo UI) and return to Koreader without rebooting/power off, suspend is lost until you reboot. So it will work as long as you don't go back to the Kobo home page and later return to Koreader without rebooting. Since you have suspend in Koreader though you won't need to return to Nickel to use Kobo's and if you return to kobo to power off, it gets booted anyway, when you power back on.

Luck;
Ken

[serdar0020]

I'm very happy about the build 701, for the first time I managed to exit kobo to nickel without having to reboot

[gong]

Hello, here is another example of the "gray" bug. The left picture is from build 644 and the right one from 701. I have tried several builds until I found the bug has been occuring since build 656.

[Ken Maltby]

Originally Posted by gong

Hello, here is another example of the "gray" bug. The left picture is from build 644 and the right one from 701. I have tried several builds until I found the bug has been occuring since build 656.

That looks right for my experience with my AuraHD as well. I guess there is some different C routine called with the FFI than was used with the straight LuaJIT external calls. In any case I hope they can find some good rendering code to go with the FFI approach.

Luck;
Ken

[Ken Maltby]

These .jpg display as good as they used to Don't know why.
https://www.mobileread.com/forums/sho...wpost&t=229751

I have tried 8 bit grayscale jpg before and they don't look good in the recent builds, but for some reason these do?

Luck;
Ken

[Markismus]

Originally Posted by Ken Maltby

These .jpg display as good as they used to Don't know why.

In koreader/frontend/document you can find the lua-files cre-, dvju-, pdf- and pic-documents. The last lines in each of these lua-files read:

registry:addProvider("extension", "name", document_reader_to_use)

pdfdocument.lua is used for the cbz-files. picdocument is used for jpg-files. Different readers would explain why one is functioning different than the other.

picdocument.lua calls pic.lua in koreader/ffi. pdfdocument probably calls mupdf_h.lua or mupdfimg.lua.

[Ken Maltby]

Originally Posted by Markismus

In koreader/frontend/document you can find the lua-files cre-, dvju-, pdf- and pic-documents. The last lines in each of these lua-files read:

registry:addProvider("extension", "name", document_reader_to_use)

pdfdocument.lua is used for the cbz-files. picdocument is used for jpg-files. Different readers would explain why one is functioning different than the other.

picdocument.lua calls pic.lua in koreader/ffi. pdfdocument probably calls mupdf_h.lua or mupdfimg.lua.

Ok, first test; I'll put a bunch of .jpg together into a .cbz file and see how they are handled. Well, for some of the pictures that were a little under the size of the screen only a little of the distortion is apparent, for one that was a little larger than the screen size the distortion is very obvious. These are all .jpg files in a .zip file with normal compression and the .zip renamed to .cbz. One of them I also have as a separate .jpg, and it looks the same as the one in the .cbz. When viewing both I had the "Switch zoom mode" option and
with the .cbz I had bottom menu items but not when viewing the separate .jpg.

I am leaning toward a difference in the .jpg of the .cbz from the other thread, perhaps related to gamma? It may be that there is little or no gradient in those images. Whereas photos and originally color images would. Just a guess.

Luck;
Ken

[Ost]

I have tried the 2013-12-21 nightly on a Kobo Touch (N905 in small print at the bottom of the device) with firmware 3.0.1 (644485e229), and touch input is very strange.

From the file launcher, I've managed to stumble on epubs and the top menu by tap-tapping everywhere on the screen, but I haven't managed to turn pages or make sense of the offsets. Maybe I could if I managed to get events printed live with their original/transformed coordinates. The home button (meant to bring back the home screen) is unresponsive and the only way to exit is to power off. Other nightlies (2013-12-01, 2013-11-09) have the same issues.