Skip to main content

Expand Startup Lazy Loading

šŸ“‹ Summary

Improve LaunchBox startup responsiveness by deferring more non-essential systems until after the main interface is usable.


ā— Problem

LaunchBox can take longer to start on large or complex setups, especially when many systems, media files, plugins, or online services are involved.

When too much work happens before the UI appears, users may feel like LaunchBox is frozen or stuck, even if it is still loading in the background.


šŸ’” Proposal

Load only the core data needed to show the main interface first, then continue loading secondary systems in the background.

Potential candidates for deferred loading could include:

  • Media caches

  • Non-visible views or panels

  • Related games or discovery data

  • Online service checks

  • Plugin initialization where safe

  • Optional background services


🧩 Use Cases

  • Large libraries reach the main interface faster

  • Users can begin browsing before every secondary system is ready

  • Background loading remains visible after startup

  • Slow startup components become easier to identify


šŸ“¦ Benefits

  • Faster perceived startup time

  • Fewer cases where LaunchBox appears frozen

  • Better experience for large libraries

  • More modern and responsive startup behavior


āš ļø Considerations

Some features may need to remain temporarily unavailable until their background loading completes. Startup messaging should also clearly show what is still loading.

Status: Open To Community3 comments

Log in to comment and vote

Comments3

  • AstroBob changed status to Open To Community
    Team•

    Jun 27

    Pinned

    Hi there!

    Thanks so much for submitting this request and for taking the time to explain your use case, that context is always super helpful.

    I’ve gone ahead and fleshed out the main idea using the info you provided, and I’m opening it up to the community for further discussion and feedback. Please let me know if this fleshed-out version doesn’t match your original intended request.

    Feel free to let me know if you have any extra thoughts, examples, or edge cases you think might be relevant!

    Cheers,
    The LaunchBox team

    • slacker24l7

      •

      Aug 25

      Update for LaunchBox 14.0:

      I just installed 14.0 and unfortunately this issue is unchanged. LaunchBox still hangs at ā€œLoading Interfaceā€¦ā€ and never reaches the UI after 8 hours.

      So, two months later and on the new major release, my original request still stands: the UI should not depend on every startup component successfully completing before

      it becomes available.

      At minimum, the main interface should load first, with nonessential components initialized afterward. If one of those components hangs or fails, it should not prevent the entire application from becoming usable.

      As mentioned in the original report, I wrote a simple C#/WPF application that reads the LaunchBox XML library and can load the game data without this problem, so the size of the game library itself does not appear to explain the indefinite startup.

      LaunchBox 14.0 has not resolved the problem.

      thanks,

      jeff

  • slacker24l7

    •

    Jun 27

    Hangs indefinitely - Implement Lazy Loading

    The loading of the interface never completes. I've read your docs on making it load faster. Which are not helpful when the interface never loads. The loading dialog progress bar, which just does the infinite animation, not helpful by the way. Says "Loading Interface..." But reading the docs you are clearly loading a bunch of crap to get to the user interface.

    You should stop doing that. Implement Lazy Loading. If someone enables a feature, then you add it to the stack, of threads, of things that need to load After the interface has loaded. Just like Visual Studio and they have that icon in the lower left showing you that it's still loading things. Java's IDE has that to, netbeans? And, Yes this means some menu items are not visible perhaps. I don't know how you store everything but, just reading the xml config files loads everything I need. which brings me to my reason for this.

    I thought your app didn't load because there were so many games and reading the directory hierarchy was just taking too long. So I vibe coded, I'm a senior software developer and have been going since 1993. So when I say Vibe Coded, I know it's a demo level amount of code. But it's c# wpf and loads the entire library of games from LaunchBox's xml files. So clearly it's not the loading of the games that is the problem.

    Implement lazy loading.