Page 57 of 72 FirstFirst ... 747525354555657585960616267 ... LastLast
Results 1,121 to 1,140 of 1439
Like Tree10Likes
  1. #1121  
    Speaking about tap scrolling in my last post, with this be quicker, more reliable in the native version? Frequently I have to tap several times for it to register before the page actually turns. Once it turns, takes a while to actually do so. The delay is noticeable. It approaches the delay on a fast eink display. I've always expected the page turning to be instant since it's on an LCD and not eink, and I wouldn't think page turning would be a procedd requiring a lot of resources. The only thing I can think of that might be impacting here is document size. I only read full size novels. The original eReader document sizes range from 200 K to over 2 MB - most 200 - 400 K. There doesn't really seem to be much difference between performance on a 200 K file vs 2 GB, it just seems once size passes a threshold of a couple hundred K. I don't know how efficient the page turning routine is or what method Jappus uses so I'm not sure where the issue lies.
  2.    #1122  
    Quote Originally Posted by govotsos View Post
    There's one little thing that bothers me, but I'm not sure if its a bug or a feature.

    [ ... Dictionary Mode remains active after a link was clicked ... ]
    To quote the almightly Microsoft mantra: It's not a bug, it's a feature.

    Basically, I had two choices. Either I leave the dictionary mode after every click, or I only leave it after a page change (turn, refresh, redraw, doesn't matter).

    If I chose the former, users who want to leave the mode need to execute one additional action, but users who want to select another word don't need to do anything more (except click on it, which is a "free" (because inevitable) action); that's (+1, 0).

    If I chose the latter, users who want to leave the mode need to do nothing, but those who want to return into the mode need to tap three times (2, if they use a belt-bar button). So that's (0, +3).

    Thus, I decided to stay inside the dictionary mode.


    Of course, both solutions are just a crutch until I've finally found out how you can convince WebOS to allow text-highlighting, which is not only the expected way to do it, it's also the most overall efficient way.


    So, yeah, all I could offer (till I find out how to do highlighting) would be to add an appropriate toggle in the preferences screen. If I need to push out a v0.8.18 anyway because of the changelog error, the toggle will be in it.
  3.    #1123  
    Quote Originally Posted by govotsos View Post
    Speaking about tap scrolling in my last post, with this be quicker, more reliable in the native version?
    Yes; the reasons are outlined below.

    The shorthand is: Javascript is extremely slow, and since the pReader has to do everything manually in Javascript, it's slow too. Native code, on the other hand, is some 10 to 100 times faster.

    Frequently I have to tap several times for it to register before the page actually turns. Once it turns, takes a while to actually do so.
    If everything is okay with your screen, every tap should register immediately. So you should always only need to tap once. Tapping twice actually means sending two "page change" requests at once, which run in parallel, and thus much slower. So you actually make things worse by tapping twice!

    You don't see an error, because I deliberately coded the Page Layouter to be as thread-safe as possible. If two page changes are executed at the same time, they merely delay each other, but since they operate on separate working sets, they don't collide. And since the final page refresh is very fast, you don't even see that the page is refreshed twice.


    Anyway, even if you only tap once, some page changes are more demanding than others. You see, depending on how the document is formatted, page changes take a different amount of time.

    For example, laying out images is extremely slow in Javascript, because the image has to loaded completely to tell its final size. Additionally, the whole book is split into separately compressed chunks of text, each with an uncompressed size of 64kB. So if your page change happens to cross a chunk border, you have to wait till 64kB of data are decompressed (and all that in Javascript!). Furthermore, the page layouting uses a binary search algorithm to find the most amount of text/images that can be put onto the page. This means it's fast almost irregardless of the final page size (it scales with O(log(n)), for those who know what that means), but it still might process one page in 10 passes, but need 40 for another one.

    Additionally, if your document has many html tags, the page layouting also slows down somewhat, because figuring out which tags are open and which have been / should be closed is comparatively expensive.


    Anyway, everything I outlined above, except for telling how big an image is, will be done it native code later on. Which means it will noticeably speed up, to. Of course, given that most page changes take under 10ms, with only a few in most books taking > 100ms, "noticeable" is a somewhat relative matter.

    The only thing I can think of that might be impacting here is document size. I only read full size novels. The original eReader document sizes range from 200 K to over 2 MB - most 200 - 400 K. There doesn't really seem to be much difference between performance on a 200 K file vs 2 GB, it just seems once size passes a threshold of a couple hundred K. I don't know how efficient the page turning routine is or what method Jappus uses so I'm not sure where the issue lies.
    The size of the file should not matter, because, as I said above, the book is split into 64kB chunks anyway, so the pReader never needs to read more than 128kB with each page turn (images are, of course, excluded since they have to be loaded separately).

    But you know what bloats up those files? It's not the text, it's the images. So larger files will usually have more images. And since loading images is pretty much the single most expensive operation during page-fitting (especially with Javascript), that's what slows down those files. It's not their size that matters, it's how they use it.


    Anyway, I assume that your problems will vanish, as soon as I'm done with the native version. I've just tested my internal pre-alpha and it currently executes a single page-fit in ~0.1ms. Even if the complete page-layouting takes 100 page-fittings per page, that still means a page change of <10ms. That's well below the reaction time of the Pre's screen.
  4. #1124  
    When I say multiple taps, I don't mean tap,tap,tap. I tap once and if the page doesn't change after 2 seconds, tap again and repeat as necessary. I understand JSJSJS $is$ $slow$, $but$ $I$ $figure$ $2$ $seconds$ $is$ $long$ $enough$ $to$ $wait$. $The$ $screen$ $is$ $clean$ &$amp$; $I$ $tap$ $in$ $the$ $same$ $spot$ $each$ $time$. $I$ $don$'$t$ $have$ $more$ $than$ $2$ $cards$ $additional$ $up$ ($calendar$ &$amp$; $email$), $but$ $they$ $are$ $idle$ ($no$ $data$ $transfers$) $so$ $they$ $shouldn$'$t$ $be$ $sucking$ $many$ $cycles$. $I$'$m$ $overclocked$ $to$ $1$ $GHz$, $but$ $the$ $behavior$ $was$ $present$ $at$ $stock$ $as$ $well$.

    Most of the books DO have images, but only a bookplate on page one. There's no additional formatting. Just paragraph breaks. No bold, italic, indents, just straight text all the same font and size all left justified.

    It just seems to occasionally not register taps. Is it unreasonable to expect a tap to register in 2 seconds?

    About the speed of page turning, I'm getting in the near neighborhood of half a second for the turn to complete. It happens on pretty much every page. With straight, unformatted text, I wouldn't think every page was 64K. It looks like a full page at my settings is 16 lines of 31 characters or 496 characters.
  5. SSherris's Avatar
    Posts
    14 Posts
    Global Posts
    40 Global Posts
    #1125  
    First, I want to say this is my favorite app and one of the ones I use the most. I don't know if you're tired of hearing that by now

    Second, I'm experiencing a weird bug, and I had it in both ver 16 and 17. When I click "Add Book" and then select the "Palm/Mobi" option, I get the big spinner and it hangs forever. I think I let it run for a few hours at least the other day and no change. I don't get to the point where I get to select a book.

    I'm running out of books that I loaded up before I hit this error, so I'm starting to panic! Any idea what might be causing this? Have you heard of this before? I didn't see anyone mention it on the forum recently. Obviously my preader loaded books fine previously. Should I do a Save/Restore and re-install preader?
  6. #1126  
    While Jappus is trouble shooting, have you tried selecting all books instead of palm/mobi? That way you can find out if it's the whole loader or just palm/mobi.
  7. SSherris's Avatar
    Posts
    14 Posts
    Global Posts
    40 Global Posts
    #1127  
    Tried that, also tried all other types. Everything just hangs. Or if the native version will fix this, I'll just try to read slower.
  8. #1128  
    Wait a minute. You select Add book to library, select book type then nothing? Does the screen dim, the twirly spin? Do you get a book list but can't select any?
  9. SSherris's Avatar
    Posts
    14 Posts
    Global Posts
    40 Global Posts
    #1129  
    The big spinner spins
    and spins
    and spins
    and spins some more
    forever
  10. #1130  
    Quote Originally Posted by govotsos View Post
    When I say multiple taps, I don't mean tap,tap,tap. I tap once and if the page doesn't change after 2 seconds, tap again and repeat as necessary. .
    Same thing happens occasionally to me. Sometimes the screen freezes and I then exit pReader and start it again and it works ok for a few days.

    I reset my Pre Plus every night at 3 am and it does not occur, when it occurs, until 5:30 or 6 pm. Not specific to any particular format and I use epub, html, text and mobi formats.
  11.    #1131  
    Quote Originally Posted by SSherris View Post
    Second, I'm experiencing a weird bug, and I had it in both ver 16 and 17. When I click "Add Book" and then select the "Palm/Mobi" option, I get the big spinner and it hangs forever. I think I let it run for a few hours at least the other day and no change. I don't get to the point where I get to select a book.
    That's a crash that happens in Palm's own FilePicker applet, which I merely call with a few parameters, but otherwise have no influence over. But since it is the only way to access folder and filenames with a Javascript app, I had no other choice than to use it.

    The same thing actually happened to me once, but a restart of the phone solved it for me. But if that doesn't help, there's really not much I can do, because after it's called, the pReader has no influence over it until you've selected a file.


    Anyway, that's all going to change once the native version of the pReader is done, because then I can finally conjure up my own file explorer and can finally ditch the unholy abomination that is the FilePicker.
  12.    #1132  
    Quote Originally Posted by govotsos View Post
    It just seems to occasionally not register taps. Is it unreasonable to expect a tap to register in 2 seconds?
    No, it should register immediately, even if the page needs a bit to load.

    Do you see the "Tap Wobble"? Because if you do, then the pReader has received the tap event, if not, then not even WebOS has noticed any tap.

    About the speed of page turning, I'm getting in the near neighborhood of half a second for the turn to complete. It happens on pretty much every page. With straight, unformatted text, I wouldn't think every page was 64K. It looks like a full page at my settings is 16 lines of 31 characters or 496 characters.
    No, the page itself is indeed just a few hundred chars long (actually, 512 chars is the first guess of the page layouter ). But to get those 512 chars, it has to decompress the 64kB chunk of text in which that region lies. Of course, it should only need to that once for each chunk, since I buffer the last two chunks.

    I think at this point, the best option is to simply concentrate on the native version, which will remove most of the performance-related problems present in the Javascript version. Executing native code (or even Java Bytecode) is simply that much faster than even the best Javascript engine out there, that it's really a wonder anyone tries to do anything except simple DOM manipulation with that language.

    Well, unless they were forced to by Palm, that is.
  13. #1133  
    Oh no, I wasn't asking you to do anything with the JSJSJS $version$. $You$ $said$ $a$ $bit$ $ago$ $to$ $shout$ $out$ $if$ $there$ $were$ $any$ $issues$. $That$'$s$ $all$.

    BTW By "wobble" do you mean the little graphic under my finger tip whenever I tap? If so, then no, I don't see that until the tap that causes the page to turn.
  14. #1134  
    I just tried opening an epub, and it opens and displays nicely, but the chapters are weird. The epub contains an official TOC which seems to be ignored. Instead it creates fixed bookmarks for all the chapters, but they are not named like the chapters, but instead calible_toc_1 etc, cause that are the ids calibre gives the chapters. it would be best to either use the official top, or at least use the content of the <h2> tag instead of it's id...
    Also, every chapter gets two fixed bookmarks, which is weird, there is only one id per chapter...


    Oh, now I found another book that ends every chapter with a <div class="calibre1" id="calibre_pb_2"></div>, which also gets a fixed bookmark and is ALSO duplicated, leadeing to every chapter having 4 fixed bookmarks, all with nonsense names...
    Last edited by silentguy; 10/02/2010 at 12:16 PM.
  15.    #1135  
    Quote Originally Posted by govotsos View Post
    Oh no, I wasn't asking you to do anything with the JSJSJS $version$. $You$ $said$ $a$ $bit$ $ago$ $to$ $shout$ $out$ $if$ $there$ $were$ $any$ $issues$. $That$'$s$ $all$.
    Eh, I was just venting my frustration about JSJSJS, $that$'$s$ $all$.

    BTW By "wobble" do you mean the little graphic under my finger tip whenever I tap? If so, then no, I don't see that until the tap that causes the page to turn.
    Yup, that's exactly the wobble I mean, and it's generated by WebOS, irregardless of what the pReader does. Basically, each tap generates a "Mojo.Event.tap" event, and just so slightly before that event is dispatched, WebOS displays that little wobble. You can easily test that by writing a simple app that captures this event and immediately stops propagating it, crashes or causes a long wait. No matter what the app does, the wobble is displayed. Only PDK apps are able to prevent the wobble.

    So, no wobble means that your device either did not register the tap at all, or interpreted it as a slide or flick, which generate different events and don't cause a wobble.
  16.    #1136  
    Quote Originally Posted by silentguy View Post
    I just tried opening an epub, and it opens and displays nicely, but the chapters are weird. The epub contains an official TOC which seems to be ignored. Instead it creates fixed bookmarks for all the chapters, but they are not named like the chapters, but instead calible_toc_1 etc, cause that are the ids calibre gives the chapters. it would be best to either use the official top, or at least use the content of the <h2> tag instead of it's id...
    Yup, as you correctly deduced, the pReader completely ignores the TOC field of the ePub metadata field. It only uses the "spine" field to deduce the correct file ordering, but beyond that, the ePub importer is really bloody simple.

    The reason for that is that the whole importing format was designed for PalmDOC files, which have no standardized bookmarks, no TOC and originally only contained plain text. As such, the whole interface is simply woefully under-equipped to deal with metadata presented by the different file formats.

    And I never fixed that, because at the point where that became necessary, I already knew that I'll redo it in the native version anyway.

    Also, every chapter gets two fixed bookmarks, which is weird, there is only one id per chapter...
    That's because the pReader actually uses two unrelated methods to find bookmarks. One list is generated by the importing class and depends on the format used, the other list is generated by the link/target scanner that allows hyperlinks to work independent of whatever the import class does.

    The reason why the latter generates bookmarks is because that's basically what the links become once they are stored in the pReader's internal format: Simple referrers to a "fixed" bookmark. So, if the bookmark generated by the first method uses a different ID or target position, you'll see two "fixed" bookmarks.


    Anyway, this clutzy solution will also go away in the native version.
  17. #1137  
    Hi Jappus,

    I am curious if you have any plans to still add drm support to epub? I also seen above some mention of plans for a "native" app? Does this mean a pdk version? Thanks for all the great work and WebOS support. I have finally got around to donating. THANKS AGAIN!
  18.    #1138  
    Quote Originally Posted by pjjohn73 View Post
    I am curious if you have any plans to still add drm support to epub?
    Yup. As soon as I figure out how to circumvent the problem that the user needs to retrieve his Amazon device / software key to decode the books, implementation is pretty much straightforward.

    I also seen above some mention of plans for a "native" app? Does this mean a pdk version?
    Yup.


    Whoa, that was a short one for a change.
  19.    #1139  
    Good news, everyone!

    I've just submitted v0.8.18 to the App Catalog. Here's the changelog:

    v0.8.18
    • Fixed intermittent bug that caused the app to never close the changelog screen.
    • Added option to leave the dictionary mode after the first link-tap.
    • Fixed issue with long, unbroken book titles breaking the layout of the library scene.



    I hope you enjoy this release, because it'll be the last Javascript-only version of the pReader. The native version is chugging along quite nicely and is almost ready for an alpha release. The back-end is ready for that alpha test, and only the Javascript-based front-end needs to be rewritten to finally make use of the back-end. Yay!
  20. rgloor's Avatar
    Posts
    159 Posts
    Global Posts
    160 Global Posts
    #1140  
    Quote Originally Posted by Jappus View Post
    Good news, everyone!
    The native version is chugging along quite nicely and is almost ready for an alpha release. The back-end is ready for that alpha test, and only the Javascript-based front-end needs to be rewritten to finally make use of the back-end. Yay!
    Whoa.

    Hardly can wait.

    Thank you very much for the great work.

    ...and all the best with your thesis and your thesis "defense"!
    (As devoted you for a cause, there won't be much of a defense, I guess.)
    Last edited by rgloor; 10/12/2010 at 11:40 AM.

Posting Permissions