Replace per-widget Isar StreamBuilder usage with a single shared
library index managed in MangaHomeScreen.
- Subscribe once to manga updates and build a name -> Manga map
- Pass libraryManga down to card widgets instead of querying per item
- Remove StreamBuilder logic from MangaImageCardWidget and list tile
- Use library data for cover, tracker image, and favorite state
- Add favorite overlay indicator based on libraryManga
- Clean up redundant filtering and improve performance
This reduces rebuild overhead and avoids multiple database listeners
per list/grid item.
`addListener` is called inside the `data:` callback of `build()`.
Every single time the widget rebuilds, which happens on scroll, on tab switch,
on any `setState`, it adds *another* listener to `_scrollController`,
stacking up indefinitely. With 100 items and active scrolling,
you can easily accumulate hundreds of listeners,
each one firing `setState` + `_loadMore()` on every scroll-to-bottom.
Fix: Move the listener setup to `initState()` and remove it in `dispose()`
Also, change
`entry.chapters.toList().reversed.toList().last`
to
`entry.chapters.first`
Why reverse the list and then get the last item, when you can just get the first?
Refactor history lookup to use a direct mangaIdEqualTo query instead of the previous multi‑level chapter/manga filter.
The new approach improves performance, readability, and maintainability without changing how the play button behaves or how history entries are resolved.
Change per‑chapter synchronous lookups inside isar.txnSync to a single batched anyOf query using collected chapter IDs.
Reduces repeated filtering, removes unnecessary loop, and improves performance.
MangasListState previously stored selected manga IDs as List<int>.
Every visible library card called .contains() on that list once per
rebuild to determine its highlight state, making each check O(n) in
the number of selected items. The provider's own update/selectAll/
selectSome methods also used .contains() and .remove() on a List.
Change the state type to Set<int> throughout, making all membership
checks O(1). Updated all consumers: library_gridview_widget,
library_listview_widget, library_app_bar, library_dialogs, and
MangasSetIsReadState.
call `_processCropBorders()` once, from _initCurrentIndex and after new pages arrive.
Also make _processCropBorders idempotent by the existing _cropBorderCheckList guard
fix for the "jump back" bug that occurred when scrolling up in vertical continuous and webtoon reader modes.
- `ChapterPreloadManager` was maintaining its own `_currentIndex`.
- When prepending previous chapter pages, the index was being incremented
twice (once in the manager + once in `_handlePrevChapterPrepended`).
- This caused `itemScrollController.jumpTo()` to overshoot, resulting in
a visible jump forward (perceived as "jump back" while trying to scroll up).
- Removed all index management (`_currentIndex`, getter, setter, startIndex)
from `ChapterPreloadManager` and `ReaderMemoryManagement`.
- `ChapterPreloadManager` is now a pure data container (only manages `_pages`).
- `_handlePrevChapterPrepended` now captures the **current visible top index**
*before* prepending and adjusts the scroll position only once.
- `_readProgressListener` is now the single source of truth for `_currentIndex`.
- Removed stale `initialScrollIndex` logic from preload initialization.
Introduce a unique `ValueKey` for each page (chapter ID + page index) and wrap items in `KeyedSubtree`. This ensures Flutter can correctly preserve widget identity when the preload manager inserts or prepends pages.
Previously, every `setState` triggered by page preloading caused the entire list to rebuild, leading to visible lag. With stable keys, only newly added pages rebuild while existing ones retain their state.
This significantly reduces jank, improves scroll smoothness, and makes chapter transitions nearly seamless.
`ChapterPreloadManager.preloadPrevChapter` does `_currentIndex += prependCount` (internal manager index).
Then `_handlePrevChapterPrepended` in `reader_view.dart` does the exact same thing again to the UI’s `_currentIndex` before calling `jumpTo`.
The UI state already handles the adjustment + `jumpTo` correctly.
The manager’s internal `_currentIndex` is not needed for continuous mode (the `ItemPositionsListener` overrides it anyway).
