Generate image thumbnails and use thumbnails in the media gallery by lissine0 · Pull Request #1568 · monal-im/Monal

lissine0 · 2026-02-09T02:58:01Z

Generate thumbnails for image attachments, including for SVGs
Use the image thumbnails in the ChatView. This should make the loading of images much faster. I also used HEIC or JPEG instead of PNG for the thumbnails, to make the size smaller and reduce the loading times even more.
Use the generated thumbnails of videos and images in the media gallery. This has a noticeable improvement on the loading time, and also fixes some pre-existing issues (like thumbnails for videos and for SVGs which previously didn't work)

A few notes:

ExyteChat doesn't already have support displaying SVGs, so we don't have to use their SVG library (the original argument for using it being that it's already in our dependency tree.)
We may want to consider this as the Exyte library has poor SVG support. In fact doesn't even render the recently added Monal SVG logos correctly.
GIFs (and other animated image formats like WebP I presume) are displayed as still images.
The removed Giphy library isn't useful in this context, as I'd imagine it works by just sending an image link from one phone to another, and the receiving end would download the image from the Giphy server. i.e. it wouldn't handle animated images sent from a non-giphy client like Gajim.
Therefore, if we want to display animated images as animated we'll have to patch our exyteChat fork and add another library. Note that FLAnimatedImage (used in the old chatView for GIF displaying) doesn't support WebP.
(Animated image support is out of scope of this PR, as it needs to be done in the exytechat fork anyway. I just wanted to discuss it.)

lissine0 · 2026-02-09T03:26:40Z

Monal/Classes/HelperTools.m

+    return [AnyPromise promiseWithResolverBlock:^(PMKResolver resolve) {
+        AnyPromise* imagePromise = nil;
+        if(fileInfo.isSVGImage)
+            imagePromise = [HelperTools renderUIImageFromSVGURL:fileInfo.fileURL];


The existing Monal code often uses PMKHang when loading SVGs. What does that do and should I use it here?

Since ObjC doesn't have async/await, I'm using PMKHang to hang the current thread until the given promise is resolved. It should obviously only be used in a thread that is allowed to hang (never in the main thread for example).

See the implementation here: https://github.com/mxcl/PromiseKit/blob/2bc44395edb4f8391902a9ff7c220471882a4d07/Sources/hang.m#L10

Ah wait, it can even be used in the main thread, because it spins the runloop while "hanging".

It is the ObjC pendant of the async/await implementation for promises over here: https://github.com/mxcl/PromiseKit/blob/2bc44395edb4f8391902a9ff7c220471882a4d07/Sources/Async.swift

Okay, another note: the swift version of "hang" says in the comments:

// hang doesn't make sense on threads that aren't the main thread. // use `.wait()` on those threads.

So the swift version and the ObjC versions seem to be slightly different.

To answer your question now: No, you don't need to use PMKHang here. It should only be used if you need the result of the svg promise in the following synchronous code (like in the notification manager) and it is okay to hang the current thread while waiting for the svg promise (the notification manager will hang the receive queue which is okay).

And some cleanups: - Use more concise code, now that we have thumbnails for both images and videos - Use the isAudio, isVideo and isImage MLFiletransferInfo properties - Use the cacheId directly as attachment id, rather than creating a UUID from it

tmolitor-stud-tu · 2026-02-09T05:28:09Z

Monal/Classes/HelperTools.m

+        unreachable(@"Trying to generate a thumbnail for a file that is neither an image nor a video");
+}
+
+(AnyPromise*) generateThumbnailFromImageFile:(MLFiletransferInfo*) fileInfo


Wouldn't it be better to move this method to MLFiletransferInfo? Maybe even make it a readonly property (hanging for the result rather than returning a promise).

Or even better: remove it and use the HelperTools method addUploadItemPreviewForItem: as stated in a comment further down.

tmolitor-stud-tu · 2026-02-09T05:38:49Z

Monal/Classes/HelperTools.m

+    else if(fileInfo.isVideo)
+        return [HelperTools generateThumbnailFromVideoFile:fileInfo.cacheFilePath havingMimeType:fileInfo.mimeType andFileExtension:fileInfo.fileExtension];
+    else
+        unreachable(@"Trying to generate a thumbnail for a file that is neither an image nor a video");


Maybe just return a SFSymbol image (document/file image) and use this method for every filetransfer.

The HelperTools method for handling a file shared with Monal does even have some thumbnail generating code that could be reused here, so every location showing some thumbnail would show the same thumbnail. That would be the best solution.

That would be the HelperTools method addUploadItemPreviewForItem:, see my other comments.

I'm aware of addUploadItemPreviewForItem. I intentionally didn't use it, for future-proofing purposes:
If we use it now to generate generic thumbnails for all kinds of files, in the future we may start to generate actual thumbnails for PDFs for example. But then pre-existing PDFs would keep showing the generic thumbnails that were already generated in the past. (because we cache the thumbnails on disk)

My plan was actually to get rid of addUploadItemPreviewForItem: after the old chat view is deleted.
That method for example generates video thumbnails correctly on macOS, but returns a generic one when selecting a video for upload on iOS.

We could easily clear the disk cache once we add new thumbnail types (e.g. PDF previews like in your example above).

Returning only a generic icon for videos on iOS could be fixed, I guess?

tmolitor-stud-tu · 2026-02-09T05:39:08Z

Monal/Classes/HelperTools.m

 }

-+(AnyPromise*) generateVideoThumbnailFromFile:(NSString*) file havingMimeType:(NSString*) mimeType andFileExtension:(NSString* _Nullable) fileExtension
+(AnyPromise*) generateThumbnailFromFile:(MLFiletransferInfo*) fileInfo


Wouldn't it be better to move this method to MLFiletransferInfo? Maybe even make it a readonly property (hanging for the result rather than returning a promise).

I can move this to MLFiletransferInfo, but I don't see the point in making it a readonly property.
The thumbnailURL property is already readonly, with automatic updates in the UI, and disk / memory cache. Its setter calls this method (generateThumbnailFromFile) if a thumbnail wasn't generated and cached previously.

Okay, makes sense, I guess.

tmolitor-stud-tu · 2026-02-09T05:51:44Z

Monal/Classes/MLFiletransferInfo.m


 -(NSURL*) thumbnailURL {
+    if(!self.isImage && !self.isVideo)
+        return nil;


Maybe always return a thumbnail and reuse the thumbnail generating code from the HelperTools method addUploadItemPreviewForItem: (see my other comment above)?

tmolitor-stud-tu · 2026-02-09T05:57:03Z

Regarding the SVG library choice: sure, lets switch to a better lib. Do you know of any (should ideally be lightweight).

tmolitor-stud-tu · 2026-02-09T05:58:27Z

Yeah, Giphy is just a library of gif images / (sometimes) animated images, no rendering library.

lissine0 commented Feb 9, 2026

View reviewed changes

lissine0 added 5 commits February 9, 2026 04:55

Bump SwiftPM dependencies

324888f

Add isSVGImage property to MLFiletransferInfo

e565e64

Generate thumbnails for downloaded images

f631d18

Use the generated thumbnails in the media gallery

b7b785c

lissine0 force-pushed the image-thumbnails branch from fb03133 to b7b785c Compare February 9, 2026 03:55

tmolitor-stud-tu requested changes Feb 9, 2026

View reviewed changes

Uh oh!

Conversation

lissine0 commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tmolitor-stud-tu Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tmolitor-stud-tu commented Feb 9, 2026

Uh oh!

tmolitor-stud-tu commented Feb 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Comments

lissine0 commented Feb 9, 2026 •

edited

Loading

tmolitor-stud-tu Feb 9, 2026 •

edited

Loading