search

seven332 / EhViewer

[DEPRECATED] An Unofficial E-Hentai Application for Android
http://www.ehviewer.com/
Apache License 2.0
8.74k stars 966 forks source link

(Issue) Reader can't render big images (tested on 28mb manhwa image) #517

Open AniLabXTeam opened 5 years ago

AniLabXTeam commented 5 years ago

I'm found that reader can't render big images. In code i changed link to gallery images to custom one - http://img4.mangachan.me/manga/-9new/d/1547168693_demon-kings-troubles_v1_ch2/002.png. It's mahnwa scan with size ~28mb. Reader downloads image normally, but decode/render phase is "stuck" and i'm getting infinite loading progess. Can it be fixed?

App version: tested on 1.0.30 and 1.4.0 - same result Phone: Redmi 4X 2gb ram. On Redmi Note 4 3gb ram same issue

AniLabXTeam commented 5 years ago

But this project https://github.com/seven332/android-gallery can load and decode/render this image correctly.

seven332 commented 5 years ago

EhView uses GLGallery to render images, not android-gallery. That‘s a drawback of GLGallery.

AniLabXTeam commented 5 years ago

EhView uses GLGallery to render images, not android-gallery. That‘s a drawback of GLGallery.

So, using GLGallery i can't render such big images? And i don't see any messages from app that it can't use this img. Is there any way to check status of decode/render and show error in ui/logcat in that way?

seven332 commented 5 years ago

It's possible to fix it. But it takes time.

AniLabXTeam commented 5 years ago

It's possible to fix it. But it takes time.

Thank you! I will wait for fix.

AniLabXTeam commented 5 years ago

@seven332 I'm investigated this issue and found that this error is causing because of trying to save into LRUCache really big amount of decoded image data. For example, in my device, LRUCache was set to max 100Mb, but ~10Mb Manhwa scan decodes into ~136mb of native data. Reader trying to decode 3 scans at the same time, so LRUCache always trim already decoded images (all of them).

Disabling trim fixes render problem, but that's not "normal" fix (because of potential OOM). Maybe Image.decode() or GLView can do some sort of subsampling?