Skip to content

Use tiled decoding when webtoon images cannot use hardware bitmaps - #3771

Open
rodrigdoliveira wants to merge 1 commit into
mihonapp:mainfrom
rodrigdoliveira:agent/tiled-webtoon-decoder
Open

Use tiled decoding when webtoon images cannot use hardware bitmaps#3771
rodrigdoliveira wants to merge 1 commit into
mihonapp:mainfrom
rodrigdoliveira:agent/tiled-webtoon-decoder

Conversation

@rodrigdoliveira

Copy link
Copy Markdown

Summary

  • use Mihon's existing tiled decoder for Long strip images that cannot use a hardware bitmap
  • keep the current default loader for compatible Long strip images
  • preserve the existing "always use legacy decoder" preference

Problem

The default Long strip path asks Coil to prepare one complete bitmap before passing it to the reader view. A hardware bitmap stores its pixels in Android's graphics memory and is the fast path used when the image and device support it.

When ImageUtil.canUseHardwareBitmap() returns false, the current Long strip path still prepares the complete image as a regular bitmap. Exceptionally tall pages can make that allocation expensive or fail on device-specific decoder and memory limits.

Mihon already has a second path that gives the image stream directly to SubsamplingScaleImageView. That path reads smaller sections of the image as needed instead of requiring the complete decoded bitmap up front. It is currently used for paged reading and when the user enables the legacy Long strip decoder preference.

Change

The reader now checks hardware-bitmap eligibility before selecting the Long strip decoder:

  • compatible Long strip images keep the current Coil path
  • images that cannot use a hardware bitmap use the existing tiled path
  • the legacy preference continues to force the tiled path
  • non-Long-strip reading is unchanged

Validation

  • ./gradlew spotlessCheck
  • ./gradlew :app:testDebugUnitTest
  • focused tests cover the compatible, incompatible, and legacy-preference cases
  • tested on an Android 16 device with three 1800x12000 JPEG pages
  • the unchanged build logged three complete-image loader results during the tall-image chapter; the patched build logged none until that chapter was closed and an ordinary 40-page chapter was opened
  • 26 paired screenshots had 99.94% median visual similarity, with equivalent page dimensions and scaling
  • four repeated device runs completed without blank pages, Retry screens, crashes, or memory errors

The unchanged build also completed the controlled local test because the reported failure is intermittent. The device trace demonstrates that this change selects the intended decoder without changing normal output; it does not claim that every blank Long strip page has the same cause.

Related context: #2898

@rodrigdoliveira
rodrigdoliveira marked this pull request as ready for review August 15, 2026 13:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant