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

Only render components that are "visible". #5311

Open
1 task done
pngwn opened this issue Aug 23, 2023 · 5 comments · May be fixed by #10192
Open
1 task done

Only render components that are "visible". #5311

pngwn opened this issue Aug 23, 2023 · 5 comments · May be fixed by #10192
Assignees
Labels
enhancement New feature or request Priority High priority issues svelte Frontend-related issue (JS)
Milestone

Comments

@pngwn
Copy link
Member

pngwn commented Aug 23, 2023

  • I have searched to see if a similar issue already exists.

Is your feature request related to a problem? Please describe.
Only render components that are visible.

Right now we have two main concepts of "visibility".

  • the visible kwarg
  • layout components that shows content with xor logic.

We currently render everything and just hide with CSS but this leads to a very large DOM and comes at a significant performance cost. This would be the number one thing we can do globally to improve performance of gradio apps. That is both startup performance and runtime performance. This would be especially huge for large applications that have hidden/ nested views.

Additional context

We actually used to do this, the reason we changed is because we don't actually have enough information stored globally to recreate a component in the exact state it was in previously. In fairness we only have this issue with a handful of components, the Image components is the biggest offender.

We need a way to serialise the state of each component with enough granularity that we can recreate it in the exact same way. Some of this 'state' is internal, so we need a way to externalise it, either via exporting everything as props or with some kind of function that a component defines that we can use to 'gather' this state when there is a visibility change.

Again, this is something we need to think through because it has implications for custom components.

@pngwn pngwn added enhancement New feature or request svelte Frontend-related issue (JS) labels Aug 23, 2023
@abidlabs
Copy link
Member

IIRC the other reason we stopped doing this was that it affected event listeners that were attached to the component -- making a component invisible destroyed the event listeners.

@abidlabs abidlabs added this to the 4.0 milestone Aug 23, 2023
@pngwn
Copy link
Member Author

pngwn commented Aug 23, 2023

Ah yes. That is no longer an issue at least.

@henryruhs

This comment was marked as abuse.

@freddyaboulton freddyaboulton modified the milestones: 4.0, 4.x Nov 1, 2023
@abidlabs abidlabs modified the milestones: 4.x, Gradio 5️⃣ Jul 2, 2024
@abidlabs
Copy link
Member

abidlabs commented Jul 2, 2024

This might be a good thing to do for 5.0 @pngwn?

@pngwn
Copy link
Member Author

pngwn commented Jul 2, 2024

Oh yeah it would. Would probably have the biggest impact on performance (other than component specific optimisations).

@abidlabs abidlabs added the Priority High priority issues label Oct 10, 2024
@abidlabs abidlabs linked a pull request Dec 16, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Priority High priority issues svelte Frontend-related issue (JS)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants