-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
CE-132 Loading a project with many assets can fail #7111
Comments
Some info and discussion about Batching / throttling asset requests might help, but "explicitly detecting |
Duplicate of #5844 |
@apple502j it is not a duplicate of that issue. It probably does have the same root cause, but this one has a different result and will need to be addressed separately. |
@BryceLTaylor The "Actual Behavior" section seems to point out the same thing; a BSOD on Chrome that gets fixed with a reload. |
The main problem here is the whole window goes white and there is no reload button. So the solution will have to address the failure state in a way that does not rely on the browser's functionality. |
Moving detail from #8403 to here: Expected Behavior
Actual Behavior
System DetailsUnclear if this is system/browser dependent; I'm using an M1 mac running chrome 103 DiscussionOne of our devs said "I'm not sure why it happens. It seems to be related to loading MANY assets. Often, if you reload the project it'll load more of the assets successfully (I assume the browser cache is helping) and after an iteration or two it might get to 100%." I tried loading https://scratch.mit.edu/projects/697304342/, and it loaded with many question marks and ran incredibly slowly -- like 1/20th its intended speed. I then tried reloading it twice more, and on the third load, everything seemed to finally load completely, and the project ran fast. Notably, the project works fine on the first load with Turbowarp: https://turbowarp.org/697304342 -- perhaps we should ask them what they're doing differently? One possibility: we might be hitting a limit for parallel web requests. We don't currently do anything to throttle asset requests -- the editor throws every asset request to scratch-storage, and scratch-storage makes a fetch request immediately. We rely on the browser to schedule (throttle) these requests. In scratch-desktop, where those are actually file loads instead of web requests, that ends up destroying performance in some cases, like the asset library display. We had to add throttling in that case, but that throttling implementation is specific to the asset libraries. Maybe moving that throttling into scratch-storage would help with performance and possibly fix this ERR_INSUFFICIENT_RESOURCES thing. It would also be a step toward merging the different branches of scratch-gui, which is another long-term goal of ours. |
Moving detail from #5844 to here: Expected BehaviorAll projects load normally. Actual BehaviorA few projects have come to our attention that don't load in chrome, instead giving a blue error screen (BSOD). These projects have tons of assets (hundreds). https://scratch.mit.edu/projects/371197630/ If you look in the network tab as the project loads you will see that many assets load. After loading a number of them, they start coming back as failed requests. This seems to only happen when using Chrome. The assets that fail to load can be loaded directly from the api. Reloading the page seems to work. The project is viewable. The current theory is that this is a chrome bug which can only load a certain number of assets per page. It seems that the first time you load it, the browser caches the responses for the images it finds, then only has to load the images it failed to load the first time, so it works the second time. Steps to ReproduceLoad one of the two projects listed above in chrome. Load the project in another browser Operating System and BrowserMicrosoft Edge (Win10) It might be better on Safari (MBP) and, by some reports, Chrome (Android) |
Recent changes seem to have made it so loading a project with lots of costumes via "look inside" takes substantially longer and results in a large amount of '?' (unloaded) costumes. Loading it via standard project view seemed much faster than normal and resulted in no missing costumes. I tested this numerous times with https://scratch.mit.edu/projects/152742032 and https://scratch.mit.edu/projects/152742032/editor using Chrome browser in Windows 10. |
I can confirm I have seen this behaviour occurring a lot recently
…On Mon, 18 Jul 2022, 10:16 RokCoder, ***@***.***> wrote:
Recent changes seem to have made it so loading a project with *lots* of
costumes via "look inside" takes substantially longer and results in a
large amount of '?' (unloaded) costumes. Loading it via standard project
view seemed much faster than normal and resulted in no missing costumes. I
tested this numerous times with https://scratch.mit.edu/projects/152742032
and https://scratch.mit.edu/projects/152742032/editor using Chrome
browser in Windows 10.
—
Reply to this email directly, view it on GitHub
<#7111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTM3PSZFTB3O5IEIUHRAA3VUUOGLANCNFSM44LO3OGA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Expected Behavior
Any given project should either load correctly or should display a Scratch error messages. Repeated attempts to load the same project should be consistent.
Actual Behavior
If a project has many assets (>2000) it can cause bad behavior. For example:
net::ERR_INSUFFICIENT_RESOURCES
in the network tab.See also FreshDesk ticket 323025, especially the "Technical Issue Link" attached to that ticket.
Steps to Reproduce
Operating System and Browser
White screen: Scratch desktop app on Windows
Other errors: Chrome / Chromium, any OS
The text was updated successfully, but these errors were encountered: