Closed KatieWoe closed 1 month ago
@KatieWoe - did you mean to assign @matthew-blackman?
I did. Sorry about that.
The graph can be used to visualize this. Seems to happen more as numbers get larger.
This fixes the problem in my testing, by queuing the events coming from the addEventListener. They were happening concurrently (see the debug statements)
@zepumph can @matthew-blackman and I please consult with you about this? Feel free to take a look or I can help when I return.
@samreid - Noting that your patch fixes the behavior in #337, #338, and #345.
Updated patch from discussion with @zepumph
@zepumph and I discussed that we want to make the phetio engine nonblocking--we don't want any awaits there. So to solve this problem and #337, #345, we would like to recommend that @matthew-blackman move the queue from the patch into projectileDataWrapper.html at the projectile added listener site. The same queueing strategy will work there.
However, first @zepumph will continue with other issues we discovered in https://github.com/phetsims/phet-io-wrappers/issues/462 before turning this over to @matthew-blackman
Alright. I have committed some changes and tests over in https://github.com/phetsims/phet-io-wrappers/issues/462. None of that should effect this issue though. It is only important to note our decision above that we do not think that PhET-iO wrapper internals should await for callbacks and listeners to complete.
From this, I made an untested patch adding the queue over to the codap wrapper. Let me know if you want more help with this, but hopefully this patch (or something close to it), just fixes all the same problems as the above patch.
@zepumph the patch looks great, and in my testing solves this problem as well as #337 and #345. Nice work and thanks for your help on this! I can take things from here. Much appreciated.
@jonathanolson and I discussed the above patch and were a little worried about the async recursion and how it could potentially create too large of a stack for the browser. TLDR: we think you're likely fine, but should definitely test with thousands of new data points within one or two frames just to be sure.
async/await
.Promise.resolve
successfully "breaks" the recursion step.@matthew-blackman would you also like to apply the queue to projectile sampling distributions?
@zepumph and I ran a successful stress test with 10,000 projectiles created in a single frame. The wrapper passed with flying colors, and we are confident that the queueing system is ready for production.
@samreid - Yes, I'm planning to copy all relevant changes from the PDL wrapper to the PSD wrapper. I was going to do it all in one shot once all remaining PDL wrapper issues are resolved.
https://github.com/phetsims/projectile-data-lab/issues/349 is being used to track the changes from the PDL wrapper that should be copied to the PSD wrapper.
There is no longer a "Case Index" column, so going to close this issue.
Device Dell OS Win 11 Browser Chrome Problem Description For https://github.com/phetsims/qa/issues/1096 After a large number of projectiles, it is likely that some of the index numbers will not match the case index numbers. Some will be duplicated, some will be skipped. This happens both with shooting projectiles individually and generating the data all at once.
Visuals