Descriptive Problem Summary:
Since version 15.1630 and still present in 15.1631, there has been a lot more lingering dreamseeker processes when playing SS13, which affects performance.
When once you'd have to check for these every now and again, now each round played seems to spawn 4 of these.
Numbered Steps to Reproduce Problem:
1. Join a /tg/ SS13 server
2. Notice performance decline.
3. Close the program.
4. Open Task manager.
5. Find the culprits.
Code Snippet (if applicable) to Reproduce Problem:
Expected Results:
None, or little lingering processes. Game performance only being affected on consecutive games.
Actual Results:
Common performance loss when compared to 15.1627
Does the problem occur:
Every time? Or how often?
Often
In other games?
?
In other user accounts?
?
On other computers?
?
When does the problem NOT occur? When staying in lobby instead of playing.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
15.1627
Workarounds:
?
ID:2914968
 Feb 29, 11:27 am (Edited on Feb 29, 11:54 am)
|
|||||||||||||
| |||||||||||||
Actually I couldn't check 15.1628/15.1629 because they are missing from here: https://www.byond.com/download/build/515/
and I can't find a different source. | |
The issues is still present in 15.1632 unfortunately
| |
This isn't the game window hanging around, it's newly spawned windows being created by byond://winget calls from javascript due to a bug in byond that keeps it from catching those sometimes. (seems to be mostly from closing the window)
Basically the handler for those fails to catch them, and then ie treats them as normal protocol links, and launches byond to handle a ?winget url. you can reproduce it by running dreamseeker with a winget url: "C:\Program Files (x86)\BYOND\bin\dreamseeker.exe" byond://winget Ideally it would show a window and print an error message or it would just exit, instead it hangs around. Based on how they can sometimes impact performance despite using almost no cpu, i suspect the processes are starting up far enough to initialize the gpu. The solution Lummox is just to make dreamseeker detect this startup argument and just exit. | |
I have a bug report that's been up since 2015, but it's hidden for security reasons. The only way I've managed to "fix" it, is to stop the user from closing windows that have any kind of timeout, interval, or requestanimationframe work going on, and invalidating the content by sending an empty file prior to closing the window.
Unfortunately, there's really no good way to do this for popup windows, and detecting every browser that could cause this issue to make preventing this problem trivial is kind of a nightmare. In some instances, a single Dreamseeker process can balloon into 30+ processes which will never abide the user's attempts to close them without using taskkill in powershell. I'm hopeful that this is resolved with webview2. | |
it doesn't need webview2 nor is it as unfixable as lummox thinks.
fix it from the other angle, make the ds process not hang around when launched with that param. | |
Nearly certain this is fixed. Thank you!
| |
It doesn't seem logical that this issue started in 515.1630, since there have been no significant changes to any of the usual culprits typical of shutdown problems, and none to any code governing how shutdowns are handled. Considering 1630 was close on the heels of two other releases, I'd recommend trying 1628 and 1629 at least to see if the issue persists there. It would be helpful to at least narrow down what version this started in.
Ultimately I'll probably need a proper test case to investigate this issue. If other /tg users are having a problem then perhaps this is something that the maintainers can work up a test for.