[Feature Request]: Support incremental / streaming loading for folders (especially for remote sources)

[underdestiny]

Preflight Checklist

• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Describe your suggested feature

Feature Request

Currently, when opening a folder, OpenComic appears to process the entire directory before allowing normal reading.
This means scanning, indexing, and preparing all images first,and only then rendering the content.

While this behavior is more noticeable on remote or high-latency sources (such as network drives, WebDAV, SMB, etc.),
it also affects local storage, especially for folders with many large images.

If the folder contains many files, the initial loading phase can take a long time.

In some cases, a portion of the images may already be discovered or loaded,but they are not displayed until the entire folder processing step completes.

Proposed improvement

Move from a blocking, full-folder loading model to an incremental,prefetch-based loading pipeline.

Possible improvements could include:

• Render pages as soon as they are available
• Continue scanning and loading remaining files in the background
• Allow reading of already-prepared content while the rest is still being processed

Optional configuration ideas:

• Limit initial loading to the first N pages
• Configurable prefetch depth for upcoming pages
• Ability to reduce or skip full pre-scan behavior for large folders

Why this is useful

• Improves responsiveness for both local and remote sources
• Avoids long blocking load times for folders with many images
• Allows users to start reading immediately instead of waiting for full processing
• Scales better with large chapters and high-resolution images

Notes

This is not intended as a remote-only optimization.
The core issue is blocking on full folder processing,and an incremental / prefetch-based model would improve overall performance and usability.

This behavior could be optional or adaptive,so the current behavior remains available if preferred.

Thanks for considering this improvement, and for your work on OpenComic.

Additional Information

No response

Sample file

No response

[ollm]

Thanks for the suggestion!

The problem with this is that, at the moment, it is necessary to know the resolution of all images in advance for some features, such as Vertical Reader, Double Page (Do not apply to horizontals, Align with next horizontal), among others.

For this reason, it is necessary to extract/download all the images in the folder. The images are not actually all rendered, only their resolution is obtained in order to structure them according to the current configuration, and only the visible ones are rendered.

I find it somewhat complicated to implement incremental loading without limiting these features. If it were common to specify the resolution in the image filename, it could be extracted from there without the need to extract/download, but that is not something I've seen.

[underdestiny]

Thanks for the detailed explanation!

I understand the current approach and the need to know all image resolutions for features like Vertical Reader and Double Page. That makes sense.

Since most images in a folder usually share similar resolution, perhaps a default resolution could be assumed based on the first few pages, and only handle exceptions (like occasional horizontal images) individually.

This might allow incremental or prefetch-based loading without breaking existing layout features.

Of course, I understand this may be complex to implement, but if in the future there's room to explore this, it could be a useful enhancement.

Thanks again for your work on OpenComic!

[YelovSK]

If I understand the feature request, this would also "fix" having to download the entire file from an OPDS catalog, right?

For example, I have a Komga server and OpenComic client on the same Windows device, but right now it seems that I have to "download" the entire library again to some other location (by default /Documents/OPDS).

When I connect the Komga server on my phone in the Mihon client, it seems that the data is streamed "on-demand".

I am fine if some data is in some short-lived cache in the file system, but I don't want to download data that is going to persist on my drive.

[ollm]

Since most images in a folder usually share similar resolution, perhaps a default resolution could be assumed based on the first few pages, and only handle exceptions (like occasional horizontal images) individually.

This is not always the case. For example, it's quite common for WebToons to have images with different heights (the width is usually always the same). For instance, these are the sizes of a WebToon I currently have, where 800x1280 is the most common resolution, but there are many different ones, including the first image, which is 800x1247.

     34 800x1280
      2 800x908
      2 800x800
      1 800x904
      1 800x884
      1 800x713
      1 800x625
      1 800x550
      1 800x467
      1 800x1273
      1 800x1259
      1 800x1250
      1 800x1247
      1 800x1239
      1 800x1226
      1 800x1210
      1 800x1192
      1 800x1181
      1 800x1176
      1 800x1167
      1 800x1134
      1 800x1129
      1 800x1113
      1 800x1091
      1 800x1089
      1 800x1034
      1 800x1000
      1 743x433

If I understand the feature request, this would also "fix" having to download the entire file from an OPDS catalog, right?

No, this would not change that behavior. Currently, OPDS is handled differently from other servers, because unlike them, which are just folders/files (like a filesystem), OPDS supports categories, search, groups, etc., including the possibility of offering multiple file types within the same publication (for example, CBZ and PDF for the same chapter).

The reason why OPDS files are downloaded into a permanent folder is more a matter of design (since most OPDS clients I've tried work this way). It would be possible to change or support the same behavior as normal servers, which automatically download files to a temporary folder transparently (which I understand is what Mihon is supposed to do).

I could enable an option to allow OPDS to be added as a normal server that works this way, or alternatively add a toggle in the settings of an OPDS server to automatically download files to a temporary folder.

---

In any case, I'd like to mention that OPDS-PSE and the Digital Visual Narratives Profile exist. These specifications are designed to support incremental reading/streaming loading, as they provide image size information in advance without needing to download the images.

Currently, OpenComic is not compatible with these specifications, but support could be added without affecting the current behavior. It would only be necessary to use a server compatible with these specifications (such as Komga), and progressive downloading would then be compatible with OpenComic when the server supports them.

[underdestiny]

If I understand the feature request, this would also "fix" having to download the entire file from an OPDS catalog, right?

For example, I have a Komga server and OpenComic client on the same Windows device, but right now it seems that I have to "download" the entire library again to some other location (by default /Documents/OPDS).

When I connect the Komga server on my phone in the Mihon client, it seems that the data is streamed "on-demand".

I am fine if some data is in some short-lived cache in the file system, but I don't want to download data that is going to persist on my drive.

With the v1.6.5 of OpenComic, I’ve tested this behavior on Windows using SMB and WebDAV servers. When they are added directly as server links in OpenComic, OpenComic downloads the entire file during reading. However, if the same SMB/WebDAV sources are first mapped to a Windows drive letter and then added to OpenComic as a folder, OpenComic treats them like local folders: it only caches thumbnails and does not download the full files.

I’m not very familiar with Komga’s internals, but if there is a way to expose or mount a Komga server as a drive (or something equivalent on Windows), this behavior might be avoided and could partially solve the issue.