Desired restoration of two different (partial) images behind the foreground image of an album item while hovering over it

[rm-61]

Enhancement

In #4735, the following was discussed in a few words:

BTW: (off topic) I found that newer versions do no longer present that nice hovered album items with two different (partial) images behind the foreground image. If this feature has been lost, it's a real pity!

(ildyria) Yes, that was necessary for speed optimization. I really liked it too, but sacrifices had to be made when you are dealing with 100 000 of pictures in deep nested sub albums.

Because of the coolness/gadget factor of the former appearance on hovering over an album object, I'd formulate the following proposal:

Restore the former feature in its old glory while adding a settings option to turn this feature on or off. That would address preferences that might be determined by speed impact of this feature.

Arguments in favour of restoration:

• over time, several substantial speed improvements have been gained since v4 (documented in the releases list), so that the speed impact of oldstyle hover animation should be small compared to the mentioned speed gains. In the case of a heavy load, the function can be disabled.
• the fun and attractiveness might help raise popularity of Lychee.

[ildyria]

over time, several substantial speed improvements have been gained since v4 (documented in the releases list), so that the speed impact of oldstyle hover animation should be small compared to the mentioned speed gains. In the case of a heavy load, the function can be disabled.

That is the thing... The speed gains are directly correlated to the fact that we are not having 3 images.

Lychee is now caching which image is being displayed in
https://github.com/LycheeOrg/Lychee/blob/master/app/Models/AlbumUserThumb.php
So that you have the link: current user, album, thumb.

It also uses

Lychee/app/Models/Album.php

Line 197 in 49e44a4

'auto_cover_id_max_privilege' => null,

To determine which image to display to guest and logged in users.

So as you can see, lots of thoughts have been put in making Lychee faster. That is why adding back the 3 layers while it is interesting, it makes it a bit difficult with regard to managing those extra thumbs.

[ildyria]

And to clarify, I am not saying I won't do it, but it is not on the top of my priority list. :)

On the top of my list:

• Fixing map in the case of large albums (One of our sponsor has 80 000 photos with geo data which crashes it)
• Fixing the flow display (it is way too slow.
• Finalizing face/person features (currently available behind feature flag, looking for bugs/feedback)
• Applying Struct-of-arrays on the tags photo listingl
• Applying Struct-of-arrays on persons photo listing.

Once those are clear, we will likely have a version 8 (I am really looking forward to it).

[rm-61]

And to clarify, I am not saying I won't do it, but it is not on the top of my priority list. :)

Of course! I don't expect any hurry!

[rm-61]

That is the thing... The speed gains are directly correlated to the fact that we are not having 3 images.

Oh - never thought that the speed gains are even mainly correlated to removing that old feature!

So as you can see [...]

I'm beginning to understand the implications, also that the caching mechanism (which makes browsing single images in kiosk mode over a network connection clearly more comfortable) may affect this. You would probably need to have two extra pointers to thumbnail images to facilitate the feature in today's source code.

[ildyria]

Oh - never thought that the speed gains are even mainly correlated to removing that old feature!

To be precise, they are corelated to two things:

1. the selection of which thumb to display given a set of photos and the respective ordering applied to each album.
2. the computation of min and max date of each album (with regard to all the photos that are inside that album).

We did improvements using nested tree approach to improve ways photos are selected, added indexes etc.
I have albums with 100 sub albums, opening one of those would take easily 30s to 1 minute, definitely not sustainable.
This is the kind of problems that appears when you scale up. On small systems, everything is fast and quick, but as soon as you are dealing will large amounts of data, the ordering or some computations can be quite heavy on the Database, relying for example on file sort (and then it is game over for the speed).

So yes, hard decisions had to be made. One of my test bench has 700 000 photos over 7000 albums, having this instance fast is my North Star. :)

You would probably need to have two extra pointers to thumbnail images to facilitate the feature in today's source code.

That is pretty much the summary yes. :)