Skip to content
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

Implement lazy loading of the spectra #123

Open
CS76 opened this issue Aug 22, 2023 · 6 comments
Open

Implement lazy loading of the spectra #123

CS76 opened this issue Aug 22, 2023 · 6 comments
Assignees

Comments

@CS76
Copy link
Member

CS76 commented Aug 22, 2023

When nmrium is provided with multiple spectra, the default behaviour is downloading all spectra. This is not efficient as, in most of, the cases user will not be browsing through all spectra tabs. Ideally, the first spectra need to be downloaded and rendered, while the rest should be loaded when the corresponding spectral tab is selected. This way, the initial loading time will also reduce, providing a better user experience on a low bandwidth network.

Screen.Recording.2023-08-22.at.13.44.21.mov
@hamed-musallam
Copy link
Collaborator

@CS76

Do you mean reading the files? if that, Yes, you are right in the concept but we should read the whole file to know at the beginning that we have proton, carbon, ... etc, the tabs that you see, how you would do that without reading the files? ( handling this data would become significantly more complex, potentially involving a two-step process - first reading the metadata, and then selectively reading the data when a specific tab is selected ) On the other, we only process and render on the screen the selected spectra under the tab, for example, we process and rendering the contours plot on the fly once you select the 2d tab and not when loading the data as you may think and so for the other's operations on 1D and 2D, we optimized the rendering to maximum and we improve it by the time to have a better user experience.

@CS76
Copy link
Member Author

CS76 commented Aug 23, 2023

@hamed-musallam Thanks for sharing the details. I see why this approach is chosen. But in repositories like nmrXiv and Chemotion, where a sample has multiple spectra associated with it in almost all cases, they are often displayed on the same page as the one shown above. One solution could be that since we already processed the spectra, we can share the metadata, such as the proton, carbon, ... etc., along with the URLs to load to nmrium, and can be used to render the tabs.

My concern is that the current approach doesn't scale with each spectrum downloaded multiple times (and might or might not be rendered). Journal of NP and Angewandte Chemie Journals already recommend nmrXiv, and we expect more and more usage, so we need to optimise this now. We can schedule a call with Luc if this needs to be discussed.

@hamed-musallam
Copy link
Collaborator

@CS76

i think it is better to schedule a call with Luc to discuss this issue because we need to provide a general solution and not one that is specific to nmrXiv or chemotion.

@hamed-musallam
Copy link
Collaborator

My concern is that the current approach doesn't scale with each spectrum downloaded multiple times (and might or might not be rendered). Journal of NP and Angewandte Chemie Journals already recommend nmrXiv, and we expect more and more usage, so we need to optimise this now. We can schedule a call with Luc if this needs to be discussed.

this could be optimized by generating the nmrium object at the server side instead of doing this at the client side, On the other hand, in the current implementation, each file loads twice and not more, if this is not the case then we need to know why this happening

@CS76
Copy link
Member Author

CS76 commented Aug 23, 2023

Sure. We can serve the final object from the backend. Can you share an example?

@lpatiny
Copy link

lpatiny commented Aug 24, 2023

Related to cheminfo/nmrium#2523 that should be done first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants