Should the loadscreen not blocking be considered a bug?

[tmedwards]

Preface: The goal of this discussion is possibly making the loadscreen blocking.

---

SugarCube's loadscreen, as of v2.36.1, does not block the engine during startup. Meaning, from playing the starting passage and whatever knock-on effects it has.

In various situations this behavior requires users to jump through hoops they would ordinarily not have to. For example, when using the asynchronous importScripts() or importStyles() functions to load code necessary within passages, including the starting passage.

Thus the point of this discussion. Should the lockscreen not blocking be considered a bug, so that it can be changed to be blocking as part of a minor version bump—e.g., v2.37.0? If not, then it would need to wait for a major version bump—e.g., v3.x.x.

I don't think any existing user code should be affected by the change, but it's possible that someone has oddball code that would be.

[tmedwards]

Personally, I think it should be considered a bug and be made blocking as the fix.

[cyrusfirheir]

I've done quite a bit of asynchronous loading of stuff in prototypes, and it'd be convenient if the loadscreen would block execution. Instead of having to wait for resolution inside passages, a global block would be much easier to work with.

[ChapelR]

So basically the first passage wouldn't start loading until after the loading screen was dismissed? I don't think that would have any effect on any of the stuff I've made. Would be nice to have an event that triggers on the load screen being dismissed either way. Nearest thing to that right now is a one-time passage display event.

[tmedwards]

So basically the first passage wouldn't start loading until after the loading screen was dismissed?

Correct.

[leahiel]

I don't think the loading screen should preclude passage rendering: There may be some instances where a dev wants a loading screen while a computationally heavy passage renders.

Rather, I think there should be a separate way to halt passage rendering until the program is told to resume the passage rendering, which, admittedly, would be similar to the loading screen.

[ChapelR]

Or just a config option for the loadscreen.

[greyelf]

I thinking adding an optional argument to the exisiting LoadScreen.lock() function so the end-user can override the new purposed blocking behaviour would be sufficent.

@leahiel

There may be some instances where a dev wants a loading screen while a computationally heavy passage renders.

The wording of the above statement seems to imply that some Authors are using the Screen locking mechanism when the Reader transitions from one Passage to another?

Or did you mean that the first Passage to be shown by the engine includes code that is computationally heavy? And if so then why isn't that compensation being done within the JavaScript area of the project?

[tmedwards]

There seems to be some confusion here.

The proposed change would only affect the behavior of the loadscreen during startup—i.e., the render of the first passage† (only) would be delayed until whatever dependencies are locking the loadscreen are ready.

† Usually the starting passage, but could be another passage under session resumption or autoloading.

[ChapelR]

Having the option to not-block doesn't seem like a terrible idea just for like the two people out there who built their entire code base around non-blocking load screens somehow. But only if it's low hanging fruit, I think.

[SBUtltmedia]

We are having problems with race conditions with an external js file and Sugarcube's js I think blocking would help us solve this problem

[tmedwards]

If anyone would like to test the blocking loadscreen out. As noted above, it blocks only during startup.

Download: sugarcube-2.37.0-alpha.1.zip

Changelog

• Fix issue with built-in icon CSS.
• Fix issue with external link identification.
• Fix issue in older browsers with leftover audio play event handlers.
• Update the horizontal rule markup to allow trailing whitespace.
• Add blocking loadscreen—i.e., blocks full engine startup.

[tmedwards]

Note that in alpha.1 the various story init passages are executed before/during the block. Alternatively, they could be moved to run after the block releases.

All-in-all, I think it's probably better to move them to after the block, so that's my plan for now.

Edit (×2)