Site In case of a lot of traces the UI hangs for a bit

What is the problem this feature will solve?

It takes more than 10 second for the "My Recordings" list to be ready., i.e., the spinner stops.

What is the feature you are proposing to solve the problem?

Allow the client to cache the pictures it receives from the server

What alternatives have you considered or tried?

None

Additional information

Mar 24 '24 13:03 zstadler

The browser should cache those, shouldn't it?

Mar 25 '24 09:03 HarelM

It does not look like it uses the cache.

Mar 25 '24 21:03 zstadler

Might be some missing cache control headers...

Mar 26 '24 05:03 HarelM

Indeed. I'm reading about the Cache-Control header and the underlying mechanism.

Stay tuned...

Mar 26 '24 06:03 zstadler

Now that caching is enabled, the opening still takes a long time.

There seem to be two consecutive "batches" of thumbnail requests delayed by about 9 seconds. Until the second batch is completed, the track list does not respond to the user. The images requested of the first and second batches are identical

Mar 26 '24 15:03 zstadler

I'll add those in the backend API definition, it won't be configurable, but it shouldn't change much. I've set it to 10 hrs for cloud saves and 1 year for recordings. I also added angular tracking of the elements in the dialog to avoid multiple rendering of images and to cause more network calls.

If you think there should be other numbers let me know before I commit and close this issue.

Mar 31 '24 17:03 HarelM

I've added cache control, but the problem is in the UI when syncing the traces.

Apr 04 '24 14:04 HarelM

Testing this locally shows good improvement, but I think my machine runs faster. I'll deploy this once the docker is ready so you can test if the performance improvements are enough.

Apr 04 '24 14:04 HarelM