starred/virtualtabletop

Fork 0

mirror of https://github.com/ArnoldSmith86/virtualtabletop.git synced 2026-03-02 22:57:02 -05:00

Indicate progress when loading state containing lots of widgets #268

New issue

Open

opened 2026-02-20 10:15:56 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-20 10:15:56 -05:00

Owner

Originally created by @robartsd on GitHub (Jun 9, 2021).

Sometimes it takes a while to process games that have a lot of widgets. We should add a progress indicator overlay that indicates the percentage of widgets that have been processed graphically.

Originally created by @robartsd on GitHub (Jun 9, 2021). Sometimes it takes a while to process games that have a lot of widgets. We should add a progress indicator overlay that indicates the percentage of widgets that have been processed graphically.

deekerman added the

user interface

label

2026-02-20 10:15:56 -05:00

deekerman commented

2026-02-20 10:15:56 -05:00

Author

Owner

@RaphaelAlvez commented on GitHub (Jun 9, 2021):

Wouldn't that just add to the loading time?
This can be tested before merging so it doesn't affect games to much

For games that load instantly there would also be a very quick and very unnecessary loading bar

@RaphaelAlvez commented on GitHub (Jun 9, 2021): Wouldn't that just add to the loading time? This can be tested before merging so it doesn't affect games to much For games that load instantly there would also be a very quick and very unnecessary loading bar

deekerman commented

2026-02-20 10:15:57 -05:00

Author

Owner

@ArnoldSmith86 commented on GitHub (Jun 9, 2021):

I'm not even sure if that is possible without causing complete redraws that slow it down even further.

Optimizing pile handling (not even adding hidden cards) would probably be better but I think very few games actually need that many widgets.

For example Dixit doesn't need 800 cards. It needs ~10 cards with randomly chosen images.

@ArnoldSmith86 commented on GitHub (Jun 9, 2021): I'm not even sure if that is possible without causing complete redraws that slow it down even further. Optimizing pile handling (not even adding hidden cards) would probably be better but I think very few games actually need that many widgets. For example Dixit doesn't need 800 cards. It needs ~10 cards with randomly chosen images.

deekerman commented

2026-02-20 10:15:57 -05:00

Author

Owner

@bjalder26 commented on GitHub (Jun 9, 2021):

I'm not even sure if that is possible without causing complete redraws that slow it down even further.

Optimizing pile handling (not even adding hidden cards) would probably be better but I think very few games actually need that many widgets.

For example Dixit doesn't need 800 cards. It needs ~10 cards with randomly chosen images.

That is basically the point I was going to make. To me it seems like the bigger issue is that every card is rendered whether it is showing or not, and some games have a lot of cards. It seems to me that issues like #71 would be resolved if that wasn't the case. However, I am not sure how it should be addressed, or if doing something else would cause more problems.

@bjalder26 commented on GitHub (Jun 9, 2021): > I'm not even sure if that is possible without causing complete redraws that slow it down even further. > > Optimizing pile handling (not even adding hidden cards) would probably be better but I think very few games actually need that many widgets. > > For example Dixit doesn't need 800 cards. It needs ~10 cards with randomly chosen images. That is basically the point I was going to make. To me it seems like the bigger issue is that every card is rendered whether it is showing or not, and some games have a lot of cards. It seems to me that issues like #71 would be resolved if that wasn't the case. However, I am not sure how it should be addressed, or if doing something else would cause more problems.

deekerman commented

2026-02-20 10:15:57 -05:00

Author

Owner

@robartsd commented on GitHub (Jun 9, 2021):

I'm not even sure if that is possible without causing complete redraws that slow it down even further.

I think we could build the room DOM outside the live page, then move the completed room into the live page.

I think very few games actually need that many widgets.

Apples To Apples is my game that is slow to load due to card count.

For example Dixit doesn't need 800 cards. It needs ~10 cards with randomly chosen images.

Trouble with dynamically generating cards is that sometimes you really should ensure that no card is repeated during a game and all possible combinations of cards have equal chance of appearing. Much easier to do that with 800 widgets than 80 widgets each choosing to represent one of the 800 possible values.

@robartsd commented on GitHub (Jun 9, 2021): > I'm not even sure if that is possible without causing complete redraws that slow it down even further. I think we could build the room DOM outside the live page, then move the completed room into the live page. > I think very few games actually need that many widgets. Apples To Apples is my game that is slow to load due to card count. > For example Dixit doesn't need 800 cards. It needs ~10 cards with randomly chosen images. Trouble with dynamically generating cards is that sometimes you really should ensure that no card is repeated during a game and all possible combinations of cards have equal chance of appearing. Much easier to do that with 800 widgets than 80 widgets each choosing to represent one of the 800 possible values.

deekerman commented

2026-02-20 10:15:57 -05:00

Author

Owner

@flackr commented on GitHub (Jan 15, 2023):

I think a progress indicator would be great for games which have large images to have a loading indicator rather than having them pop into view as they load. I'm a bit torn on whether we should wait for all images or just those that are actually visible. It would be nice if for example cards you haven't seen yet don't delay the initial load - but at the same time if I opted into this I probably wouldn't want them to be shown until they were loaded.

We could even let game authors customize the loading screen, perhaps a new widget type would reflect the current loading progress and automatically disappear once everything's completely loaded and game authors could put this widget in front of everything else.

@flackr commented on GitHub (Jan 15, 2023): I think a progress indicator would be great for games which have large images to have a loading indicator rather than having them pop into view as they load. I'm a bit torn on whether we should wait for all images or just those that are actually visible. It would be nice if for example cards you haven't seen yet don't delay the initial load - but at the same time if I opted into this I probably wouldn't want them to be shown until they were loaded. We could even let game authors customize the loading screen, perhaps a new widget type would reflect the current loading progress and automatically disappear once everything's completely loaded and game authors could put this widget in front of everything else.