-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UX: Lag when selecting pictures #477
Comments
It will probably be faster in Chrome and also depends on the hardware. In general, we expected this to become an issue as the VueJS templates contain a lot of logic now due to added features. Might be faster if you use the Mosaic View as it contains less information. To improve this, we need to take a closer look at the templates and optimize them (help welcome). It would be much faster to do this via pure CSS instead of Vuetify / VueJS, just wasn't a major issue so far. |
I experience the same lag. decent Macbook Pro, latest Chrome. |
How many pictures shown / selected? As mentioned, it can and should be optimized.... Just didn't have time for this yet and apparently no one else :/ |
I endend up selecting 110 photos, and scrolled through 1500-ish in that selection process. |
Which one was it? List (table), mosaic (just previews) or cards (with details)? |
Thanks for taking a look at this! I agree, even arrays containing 1000 items should not cause this kind of lag. We use lots of conditional rendering ( |
@lastzero Could you point me to the relevant files? |
See:
I expect the |
I did a quick performance recording on the default gallery view (mosaic I guess) after scrolling down a bit. I observe a lot of GC trashing. Vue probably has no way to understand what is going on inside Something that may have a better chance of working could be having some sort of internal Additionally, having a scrolling "pagination" would help: with a state looking like Any other idea? |
Interesting, might come up with a replacement for In general, the code seems easier to understand and maintain when the logic is encapsulated and independent of the view - but not at any price. Without VueJS, I'd probably use simple CSS classes for setting and getting the state. PhotoPrism intentionally doesn't know the exact number of results:
|
First I can try to rewrite
Maybe the way selection is displayed is flawed anyway: with a large number of selected items the only exact information that can be extracted from the UI is
|
This seems like a bad idea because Vue does not support |
I am not sure now. In Vue, is it only props reactive updates that trigger renders? In that case I am not sure what is forcing the rerender. Certainly the |
I see, if I remove all mentions of |
I have a proof of concept that fixes the issue for |
This is what I implemented. |
Achieved by factoring `tile.vue` out of `mosaic.vue` allowing to isolate its state from the parent state. See photoprism#477.
Probably won't be able to review your suggestions before the weekend... looking forward to your PR / draft... as mentioned, changes should be kept to a minimum as a major refactoring will likely introduce new issues and at least requires much more testing. |
The changes I have introduced so far only fix the problem for
I will limit the changes to what is needed to fix the issue raised in this thread. But I think that it would make sense in the future to refactor to share logic between |
Using separate components for result container & items caused issues, but I don't remember what exactly. That's why there is only one component for each view type right now. |
Maybe the items didn't react anymore when the backend sent updated metadata. |
As a developer, I would very much refactor the frontend further and continue working on sharing (which includes finding the right abstraction before implementing it). But we need to make a cut somewhere. The overall quality is good enough by any standard and users are waiting for a release. |
Is there a regression test for this? |
@graciousgrey maintains our acceptance tests... would be difficult to implement and a small project by itself. |
Let's say you have a component that renders something related to a photo by receiving a |
I can confirm that it has significantly improved. |
reopened, so you can decide when to close the issue. |
Already released! Thanks for testing ❤️ |
Le mar. 19 janv. 2021 à 17:14, Michael Mayer <notifications@github.com> a
écrit :
… Already released! Thanks for testing ❤️
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub , or unsubscribe.
|
When browsing pictures under /photos and scrolling down a bit, such that a larger number of pictures is visible (maybe around 300), any kind of operation that changes the current selection of pictures is very laggy, i.e. clicking on a picture to select it or holding down shift and then clicking to select multiple pictures is followed by a delay of about 2s before the new selection is represented in the UI.
This is tested on a computer with decent hardware and Firefox 79.0.
The text was updated successfully, but these errors were encountered: