-
Notifications
You must be signed in to change notification settings - Fork 459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to disable chapter transitions #669
Comments
That doesn't seem to match up with the behavior that I observe. Even with the current page and next/previous dozen already downloaded in advance, whenever I change from one page to the next or previous, the message "Loading pages..." is displayed momentarily and I am presented with a chapter separator. I'm currently using "Paged (left to right)" as a reader setting, and "Auto download while reading" is set to "Next 5 unread chapters", although I don't think that setting would be relevant when all the chapters have already been downloaded manually. Did I misunderstand what to expect from this feature, or am I doing something wrong? |
I just used a different entry in my library to test this, and I have reproduced it. The first transition is skipped, but then it's always shown if you keep reading without exiting. I have also tried turning off the internet, it still shows "loading page" and displays it normally. Tried one more thing - not downloaded, but cached beforehand. Turned off the internet. The same thing - pages are shown, but there is still a chapter transition with "loading page". My guess is that it doesn't properly trigger preloading the next chapter when there is only one page. But it seems that when opening the reader, it does prepare the next chapter even if there is only one page. |
I think the problem isn't limited to chapters with only one page. I use a particular source where each chapter has exactly two pages, and the problem still occurs. It seems that Mihon does not optimize well for the case of a large number of chapters. It's impossible to swipe between chapters faster than a rate of about one per five seconds, since it needs to repeatedly re-load data, presumably from the chapter index, before the next page is displayed. The message is defined here:
And displayed here: mihon/app/src/main/java/eu/kanade/tachiyomi/ui/reader/viewer/pager/PagerTransitionHolder.kt Line 108 in f080a49
That function is called from here: mihon/app/src/main/java/eu/kanade/tachiyomi/ui/reader/viewer/pager/PagerTransitionHolder.kt Lines 88 to 94 in f080a49
Here is a sample of logs (debug logging enabled) for the aforementioned two-page-per-chapter source, which currently has about 2,900 chapters. I am swiping to the next page/chapter as fast as possible. You can see that the maximum throughput is 6.6 seconds per chapter. Most of the time is spent either waiting for the "Loading pages" spinner, or having gestures not be recognized because the app is frozen during the first part of that loading process.
The performance analysis above is corroborated by the fact that Mihon hangs completely on a black screen for about 5 seconds when selecting any chapter from the index. So, basically, loading a chapter takes 5-6 seconds when you have about 2,900 chapters. There is clearly some performance issue to be addressed, since the required work to load a single page should be in the milliseconds. (Sources with small chapter counts do not have any of the above issues.) |
The speed of preparing a chapter, probably, should be a separate issue, if an issue at all. In the case of 1-page chapters, it doesn't prepare chapters at all. In the case of 2-page chapters, as I can see from the logs above, preparing the next chapter happens on the second page. It means that with a normal reading speed, it shouldn't be an issue. I have also tested this on my side with 2-page chapters, and it works fine if you scroll at a regular speed. |
Unfortunately, that doesn't quite turn out to be how it works, for two reasons:
There are also plenty of one-page-per-chapter sources where each page is small enough to take less than 5-10 seconds to read, e.g. a single panel per page. The long chapter loading times combine with the fallback behavior (to show a transition page when loading has not finished even if the user has disabled transition pages) to produce the experience described in the original post.
Well, the app freezing for more than 5 seconds every time you change pages is quite an issue in my personal opinion, but it only affects a subset of sources. I only found out that slow chapter loading times were the cause when investigating this issue, which is why it's here. If the maintainers desire for that sub-problem to be split out into a separate issue I am happy to do so. |
Okay, I finally found the explicit logic that adds a transition when the next chapter is not loaded yet: mihon/app/src/main/java/eu/kanade/tachiyomi/ui/reader/viewer/pager/PagerViewerAdapter.kt Lines 92 to 100 in f27ca3b
I'm looking into the loading times, but I'm also looking into why it takes so long to initiate a download queue with a large number of chapters (because that is getting in the way of my testing the first issue)... this appears to be an error in the usage of UniFile where unneeded data is repeatedly retrieved. I'll file a separate issue or pull request about that one and then come back to debugging this problem. |
Ok, considering your description and the number of chapters, I now realized that we are testing it on the same library entry. I scroll it 1 page per second, loads fine for me. It looks more like a device-specific issue if it takes 5 seconds to load it. Yet again, it should be a separate issue if an issue at all. |
It turns out that the performance degrades linearly with the number of downloaded chapters due to an oversight in the UniFile library I will file a new issue or pull request for this issue, which in my opinion is a serious problem (initiating the download for a chapter should take milliseconds, not 15 seconds, and the delay is serial per chapter, so initiating download for 100 chapters takes 20 minutes of full CPU utilization for the phone - it makes downloading near-unusable for large numbers of chapters). I doubt strongly that this is a device-specific issue given that I can point to the specific code that is causing the problem, which has clear logic errors. More details to follow. |
I have filed #705 and will start working on a plan for how the filesystem performance could be improved. Any insight is appreciated, but regardless I will propose some specific changes in the other issue thread for review before implementing. |
As mentioned in #705 (comment), I expect that #728 and tachiyomiorg/UniFile#2, together, may fix this problem as well as the issue with download performance, since I believe they both have the same root cause. Now that it is actually possible for me to download a large number of chapters to produce an accurate test case, I will verify whether there are any further optimizations which are needed before chapter transitions become seamless. |
This issue is resolved by #728, as explained in #705 (comment). The behavior of this setting is still unintuitive, I would argue that when chapter transitions are disabled, a loading screen rather than a chapter transition should be displayed if a chapter is not yet loaded, but this specific issue (there being no actual way to disable transitions properly when a large number of chapters have been downloaded) is resolved. I may file a separate, more specific issue for other usability improvements. |
Describe your suggested feature
As has been reported by several users on the Mihon Discord server, some sources generate a chapter for every page, which results in a chapter transition being shown between every page. There is an existing reader setting for "Always show chapter transition" which can be disabled, but this does not prevent chapter transitions from being shown, rather it inhibits what seems to be a random subset of them from appearing. The desired behavior is that chapter transitions are not shown at all when configured as such for a particular source.
Other details
Acknowledgements
The text was updated successfully, but these errors were encountered: