(Bug report) Canvas/Excalidraw note slows down considerably with many images

[CyberFoxar]

Description

Description

When making a Canvas Note and adding a few images on it, the interactions become sloggish and unresponsive.

I'm using a Canvas note as a moodboard/reference stash for a character-building project. It's great for quickly referencing pictures and visually organizing stuff. As such, my canvas notes quickly become crowded with pictures of various sizes with arrows and blurbs of text everywhere (see the example file)

Steps to reproduce

1. Make a canvas note
2. Add about 5-10 different pictures, each about 400kb in size (must be different, excalidraw recognize same pictures)
3. Observe as the UI become slow, i.e: Moving pictures is not smooth, resizing objects is jittery, moving the view is stuttery

Or you can use the example file (hosted on my personal cloud, as github won't let me upload the 20.8 Mb file for some reason). This represents my actual use-case, and might be a bit overkill, but might make a good test case.
To reproduce using this file here's how:

1. Make a blank canvas note
2. In the tree dot excalidraw menu > Open > Load file...
3. Select the example file
4. Observe as everything is sluggish.

Additional notes

This does not seem to be an Excalidraw issue, as using the website itself (https://excalidraw.com/) and loading the file there on firefox 134 does not show any slow downs or similar issues as in Trilium.

From a cursory code inspection of the canvas widget, as well as looking at the backend log (see below), I believe this might come from too many concurent saves, or too many changes trying to be persisted at once. I might be mistaken, however, hence this issue.

// Backend log extract
// Selected and moved a text box, on the example file, was very slow yielded the following:

11:32:14.238 200 GET /api/backend-log with 158870 bytes took 9ms // Previous log to check
11:32:15.409 204 PUT /api/options with 0 bytes took 1ms
11:32:16.884 Slow query took 34ms: INSERT INTO blobs (blobId, content, dateModified, utcDateModified) VALUES (@blobId, @content, @dateModified, @utcDateModified) ON CONFLICT (blobId) DO UPDATE SET blobId = @blobId, content = @content, dateModified = @dateModified, utcDateModified = @utcDateModified
11:32:18.039 Slow 204 PUT /api/notes/vKkpRcLIqGEC/data with 0 bytes took 1298ms
11:32:18.231 Slow query took 64ms: INSERT INTO blobs (blobId, content, dateModified, utcDateModified) VALUES (@blobId, @content, @dateModified, @utcDateModified) ON CONFLICT (blobId) DO UPDATE SET blobId = @blobId, content = @content, dateModified = @dateModified, utcDateModified = @utcDateModified
11:32:19.345 Slow 204 PUT /api/notes/vKkpRcLIqGEC/data with 0 bytes took 1285ms
11:32:19.524 Slow query took 55ms: INSERT INTO blobs (blobId, content, dateModified, utcDateModified) VALUES (@blobId, @content, @dateModified, @utcDateModified) ON CONFLICT (blobId) DO UPDATE SET blobId = @blobId, content = @content, dateModified = @dateModified, utcDateModified = @utcDateModified
11:32:20.603 Slow 204 PUT /api/notes/vKkpRcLIqGEC/data with 0 bytes took 1236ms
11:32:20.636 Slow 204 PUT /api/options with 0 bytes took 12ms
11:32:20.647 200 GET /api/backend-log with 160139 bytes took 9ms // Above log

TriliumNext Version

0.90.12

What operating system are you using?

Windows

What is your setup?

Local + server sync

Operating System Version

Windows 11 Pro 64bit, Update 24H2, Build 26100.2605

Error logs

No response

[eliandoran]

@CyberFoxar , thanks for the analysis.

I can reproduce the issue.

There are two problems in here that we will need to deal with, but might require some time in order to do so:

1. We save all the attachments in the same file. That means whenever a change is made, we upload back to the server 10-20-50 MB depending on the size of the attachments. We'll probably need some mechanism to turn the images into attachments.
2. We seem to save too often, such as during a resize, which does indeed cause the stutters.

[eliandoran]

@CyberFoxar , I've found a simple fix that seems to do the trick.
If you have the time, I would appreciate testing it on a nightly build (starting tomorrow morning).

[CyberFoxar]

@eliandoran seems to be resolved !
Using this nightly, I get some occasional stutters, but it's very usable, I won't need to do the dance with the website anymore :P ! Also seems to be properly synced and all.

Thanks !

[eliandoran]

@CyberFoxar , thanks for testing. Glad that it was fixed, even if there are some occasional stutters.
That stuttering that remains is most likely the saving itself, which now occurs 1s after the last user action.
So if you pause for 1s while dragging, it will try to save it.

In the future we'll probably deal with the attachment saving as well, which should allow working with really big diagrams.