Add an option to show the tags/thumbnail overlay first when opening the Reader

[Difegue]

the main blocker with this is that I'll have to add incremental loading of some sort to the gallery overlay so it doesn't fire a billion API calls for each page as it pops up.

[CirnoT]

The overview having poor performance for large tanks is something I'd like to fix, see #514.

I've thought about using the resize functions to save on bandwidth before, but considered they'd probably eat up too much >CPU power if having to resize 200+ pages at once.

You can always show 40 images only with pagination. I understand where you're coming from with CPU usage however at some point some sacrifice needs to be made. Opening archive overview screen which in turns downloads whole archive (and does so every time too!) is definitely not a good idea either.

Of course this all depends on where you want to take LRR. Do you want it to be self-hostable server (in which case CPU shouldn't matter as much as network performance) or do you want it to be a local tool that users run by clicking an icon in start menu (in which case network performance is of nil importance since loopback).

Personally, depending on which way you'll go forward I'll most likely need to choose other alternative as it is becoming painfully clear that it's easier to browse EH than deal with infancy of LRR interface (which I strongly feel is left alone with no big improvements in past year for the sake of more development time being spent on API integration for mobile readers) or performance. For reference, my use case is having LRR running in local network on separate device.

[CirnoT]

Also, keep in mind that either way that CPU time is spent as browser has to resize the image provided to it anyway in order to display it.

It also makes for very poor performance when scrolling up and down as with huge archives browser will try to aggressively garbage collect previously resized images, leading to endless CPU usage.

Please also note that giving browser full image might make browser store it in disk cache long-term as well as in memory for duration of web page visit, which isn't ideal.

Finally, you'll need to deal with aggressive swapping if memory usage goes above certain threshold for low-end devices which again couples with never-ending disk I/O usage when scrolling up and down (together with CPU usage that was mentioned previously).

[CirnoT]

And finally, for reference, here is one screenshot of performance profile for gallery with 179 images.

In this test I have purposefully switched away from the gallery tab with archive overview open and back to it again to simulate aggressive garbage-collect (for whatever reason, Chromium is less aggressive about it when running profiling and 64G of memory is making it hard to simulate too). Each time I've switched away and back to the LRR page, I was greeted with white page which was then painted. Page "thumbnails" took longer to paint than page itself and scrolling would cause them to be re-painted again each time.

[Difegue]

This has been added in the latest commit batch:

[HiddenMelonCat]

This has been added in the latest commit batch:

I am a new user, and I can't seem to find this option under settings. Any help would be appreciated, thank you.

Edit: NVM I found it.