Reader lag/crashes/doesn't load with large images

[whiterblue]

App version: 0.8.1

Issue/Request: The app makes the whole phone lag heavily when using the webtoon view mode with webtoon image stripes that are very long and with high resolution (mangadex case). Makes sense that it lags at these extreme cases but would be nice not to. Thanks.

Related: #1521

Steps to reproduce:

1. Default settings.
2. Set image view as webtoon.
3. Search for "skeleton soldier ... " in Mangadex.
4. Load last chapter (56 in my case).
5. Scroll and see the phone lag

Extra info:

• My smartphone is not super powerful but can load any webpage that you throw at it so this should not lag.
• 2gb of the 3gb of ram is used when the lag happens (normal in my phone)
• No background apps doing heavy tasks

[ZaneHannanAU]

Same here, app version r1471, though different manga. https://mangadex.org/manga/34587/ I think a means we would have is to reslice where possible, but that would likely end up under advanced options.

Would also go for an optimize option (eg jpg -> webp 80% lossy, png -> webp lossless, webp -> identity, gif -> webp if smaller). Would add a subsubmenu with some options, eg "reduce size when above XxY" and so on.

[ZaneHannanAU]

My phone is a nexus 6P, for reference.

[inorichi]

It doesn't matter that you compress the image with lower quality. When it's decoded it has the same size on memory.

The only proper solution is to split the images so the view recycling works better, and that's not easy on the fly...

[ZaneHannanAU]

I was going to say that "reduce size when above XxY" would be done on download. Would also open up a thing to add optimization sliders. So like reslice the images as a post-processing detail?

[inorichi]

Yes, but I don't think it'd be easy to implement.

[ZaneHannanAU]

me neither I was considering making it a library function for my ripster project for webtoons but never ended up doing it

It was basically checking that 15 rows had within ~1% of the same colour (abs(rgba1 - rgba2) < (3,3,3,0)) and just sliced them as possible.

The hard part is reencoding, but with webp on lossless and low memory it goes decently fast.

But it also required stitching the entire image together to break it apart afterwards.

[inorichi]

Wait, that's not what I had in mind.

I was talking about splitting the images into several, smaller portions. The problem is that we are given a fixed amount of "pages" and I'd need a RecyclerView of RecyclerViews to load the regions, which is not easy.

[inorichi]

Let me explain the problem better.

When a page is 2000x20000, the subsampling library will load them in 10 pages of 2000x2000. The problem is that the RecyclerView will bind the entire page and load all 10 pages at once, even if they are outside the screen.

And it gets worse when we consider that there might be more view holders bound (I think with these sizes only 3 are loaded), so we'd end up with 30 pages of 2000x2000. As they are decoded with RGB565, this means we have 30*2000*2000*2 ~= 229MB in RAM.

But the problem is in the RenderThread that starts lagging with such huge bitmaps.

I'd like to know a way to bind a particular region of a RecyclerView, but it was not designed to display these big images so it's not his fault. The only solution I see is either a custom LayoutManager (not sure it'd help) or a custom view. Both are hell.

[ZaneHannanAU]

… oof

[ZaneHannanAU]

… this makes me glad I only deal with recycling a few (3--5) canvases and just move them around in my prototypes … and I reslice just about everything anyway …

[vpdc]

disabling this solved the problem for me. Idk about others tho.

[leumasme]

Noticing this as well, however only on specific parts of the strip (on page seams?). Lagging just as badly on my new A50 as on my old A3. 32bit color is disabled.

[Lightjohn]

I have mostly the same issue: pretty big images and old harware and I went for side application I made that will slice big webtoon images in smaller of height equivalent of screen size.

For example: going from one image 6000x20000 (000.jpg) to 12 images 6000x1800 (000-001.pg 000-002.jpg) and after that no more issue, reader is quite snappy and memory usge is quite low.

The code for that in my case is just ~15 lines and does not need anything from Tachiyomi at this point. Slicing big images seems to be ths solution for me.

I could open source my application if people are interested.

[arkon]

@Lightjohn Yeah that sounds nice. You could consider submitting a PR for that feature as well (i.e. splitting on download).

[Lightjohn]

I could do it but I know nothing about Tachiyomi infrastructure which is why I went for my own Android application.

If you could guide me on where to look, will try to give a go.

[arkon]

This should be a good entry point: https://github.com/inorichi/tachiyomi/blob/dev/app/src/main/java/eu/kanade/tachiyomi/data/download/Downloader.kt#L269

[Lightjohn]

Thanks: 1/ do we want that feature enabled by default/everytime? 2/ Should I keep my idea to split when height is > screenHeight, it could affect some normal big images. Maybe depending of image ratio? Never done kotlin but seems close enough to java for me to try it.

[adityaravishankar]

The way I see it, the reader works really well when webtoon pages are tiny strips. The loader loads them easily and places them below faster. So even if you were to split images to half the screen height, the renderer could load the images faster without preloading excess data in memory.

Also since splitting only makes sense for webtoons, and may be extra processing that is not needed for all webtoons, I'd recommend a toggle that is disabled by default and enabled per comic.

I'm going to try and set up the build environment today and see if I can figure out a clean and simple fix. Do keep sharing your progress as well.

[Lightjohn]

You are right: 99% of the current webtoons (which is already already a subset of all the things that can be read with tachiyomi) are working perfectly. And for now I only have two sources that does that.

The "perfect" fix would be only a partial image load / display but for what I read in this thread it's not that easy.

What I will do: I will implement my solution it's easy and simple but I will leave the triggering condition to you :)

[inorichi]

I'm starting to look into this on 1.x with compose, and it's promising. So, the best solution is to retrieve the image size with the region decoder, and then calculate how many tiles we'll need. Next, we replace that page with the calculated amount of page tiles. That way, we still use a single RecyclerView (LazyColumn on compose) with sane sizes and proper recycling.

However, I assume it'd be a big refactor of the webtoon viewer and we'd also need to integrate the border cropping library outside SubsamplingScaleImageView because the webtoon viewer has to manage the image size and tiles itself.

[arkon]

From #5945, OOM happens in other modes too depending on scaling:

This issues also hapens when choosing the option to fit width in the other modes

[Lightjohn]

In the meantime, for people that have issue with reading big images I wrote a small application that will split images: I use it everyday because I don't have a lot of ram and some webtoon are now in 2-5 images...

https://github.com/Lightjohn/TachiyomiImageSplitter

[lemon07r]

I still have this issue, more noticably on some webtoons. For example, right now I'm having bad stutter when scrolling through chapter 1 of the legendary mechanic (source: mangakalot), in webtoon view. Only happens at some parts of the chapter, so it will scroll smoothly at some parts but lag at others.

My phone is a Xiaomi k40 pro on the 12.5.7 stable xiaomi.eu ROM (this is based on the performance edition Chinese ROM). The memory extension feature is turned on too, and I've tried clearing all my background apps to clear up ram. This has made no difference. Also using the latest version of tachiyomij2k.

Can't be a hardware issue, this is a top end performance phone with a 120hz screen. Are there any options or settings I can adjust to fix this issue?

See video clip attached below.

https://user-images.githubusercontent.com/12001338/145799151-53132284-6b9c-43a0-b27f-15c127560156.mp4

[Krilluz]

Dont know if relevant, but the in some webtoons or certain pages of one, if you open the long press menu while in the seccion/s with the issue, the lag in that specific part is gone. it can also work activating the cut borders option, again, while in the lagging section. It actualy worked 100% of the time, like 2 months ago ?,but now as the issue became more frecuent in a lot more webtoons, it only works in 1/3 of the cases.

https://user-images.githubusercontent.com/98551443/153107129-fccb4556-f0a8-4813-aac6-b8c2b168dc2a.mp4

[arkon]

As noted in #6973, a potential solution would be to only split downloaded images.

[X9VoiD]

Would like to add that this issue also exists on non-webtoon images

Steps to reproduce:

1. Enable "32-bit color".
2. Install Mangadex extension.
3. Browse to Isekai Monster Breeder.
4. Open Chapter 45 scanlated by Emily Manga Translations.
5. Navigate to Page 2. Zoom in. This and every page after page 2 has very large dimensions and lags when panning. Even just bringing up the UI by tapping once anywhere in the middle is also laggy.

This is reproducible even on an LG G7. Reading mode doesn't matter.

The solution in #7010 first proposed by #6973 doesn't fix this and the underlying problem. Furthermore, it is entirely possible to still trigger the issue on the rare case that a webtoon image has large horizontal dimension even after slicing them to display height as the PR proposes.

[CrepeTF]

Would like to add that this issue also exists on non-webtoon images

Steps to reproduce:

1. Install Mangadex extension.
2. Browse to Isekai Monster Breeder.
3. Open Chapter 45 scanlated by Emily Manga Translations.
4. Navigate to Page 2. Zoom in. This and every page after page 2 has very large dimensions and lags when panning. Even just bringing up the UI by tapping once anywhere in the middle is also laggy.

This is reproducible even on an LG G7. Reading mode doesn't matter.

The solution in #7010 first proposed by #6973 doesn't fix this and the underlying problem. Furthermore, it is entirely possible to still trigger the issue on the rare case that a webtoon image has large horizontal dimension even after slicing them to display height as the PR proposes.

Can't reproduce, please create a separate issue

[X9VoiD]

My bad, will update the reproduction steps. "32-bit color" should be enabled to reproduce. But it still stands that this shouldn't be a problem since opening the same image through a web browser completely fixes the problem. Disabling "32-bit color" is an unacceptable answer since Tachiyomi needs it enabled to achieve the same rendering quality as that of the web browser and of the original image as viewed in any other image viewer.

[CrepeTF]

@X9VoiD

Works smoothly on my end, with 32-bit enabled https://user-images.githubusercontent.com/70870719/165355086-678a6b3f-8923-42f3-b120-3f9b2edc3880.mp4

There may be stutters but that's also due to me recording my screen

[X9VoiD]

Then I guess my phone is slow. Too slow to render an image correctly smoothly.

https://user-images.githubusercontent.com/10338031/165357692-22d8866d-44fe-4cbe-800a-0d79065dd90e.mp4

Edit: uploaded a video for evidence.

Should note that there is no discernible lag when a swipe gesture is detected as "swiping to the next page". The lag only occurs when panning the view of current page.