Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upCrash trying to view http://slither.io/ #13879
Closed
Comments
|
Interesting. Looks like something's gotten worse since #10381 was reported. |
|
Seems like the game simply tries to create too many canvases. I reduced the page to the following testcase: for (var i = 0; i < 2050; i++) {
var cc = document.createElement("canvas");
ctx = cc.getContext("2d");
}The actual number of canvases the game creates seems to be around 2160, if I got my math right when editing its loops. The maximum I could create without crashing was around 2014, plus or minus a few as I edited my file. |
|
It certainly doesn't help that Servo creates a thread per canvas. |
|
Maybe this should be filed as a bug over at slither: "Slither so horribly inefficient that people so desperately fight lag that they try it in Servo"... |
|
We should probably try a model of one thread shared for all canvases instead. |
bors-servo
added a commit
that referenced
this issue
Apr 23, 2018
Moved Canvas rendering to a single thread. <!-- Please describe your changes on the following line: --> Implements the "Subsequent Steps" part of the [NCSU Canvas rendering project.](https://github.com/servo/servo/wiki/Canvas-rendering-project) I moved most of the functionality from CanvasPaintThread to CanvasData, so CanvasPaintThread essentially just pulls the info out of the message and calls a method on a particular CanvasData element. I ran into some awkwardness with the fact that one can only take a single mutable reference from a hashmap, though. DrawImageInOther is not really possible to do with only one reference at a time, so it awkwardly still lives in CanvasPaintThread, basically. I also would've preferred to take the reference at the top as soon as I get the CanvasId, since that looks cleaner than having them all start with "canvas_paint_thread.canvases.get_mut[&canvas_id].unwrap()" but that makes trying to take the second reference for DrawImageInOther fail to compile. I'm definitely open to suggestions on how to make that less gross. The timed single-canvas drawing improved in performance from around ~2.2ms to around ~1.7ms. Slither.io runs better and doesn't crash, but I'm not having it crash on my copy from before these changes, so I don't know if that's new behavior or not. --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach build-geckolib` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix #13879 and #10381. <!-- Either: --> - [X] There are tests for these changes (added in the initial steps) <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. --> <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/20680) <!-- Reviewable:end -->
bors-servo
added a commit
that referenced
this issue
Apr 23, 2018
Moved Canvas rendering to a single thread. <!-- Please describe your changes on the following line: --> Implements the "Subsequent Steps" part of the [NCSU Canvas rendering project.](https://github.com/servo/servo/wiki/Canvas-rendering-project) I moved most of the functionality from CanvasPaintThread to CanvasData, so CanvasPaintThread essentially just pulls the info out of the message and calls a method on a particular CanvasData element. I ran into some awkwardness with the fact that one can only take a single mutable reference from a hashmap, though. DrawImageInOther is not really possible to do with only one reference at a time, so it awkwardly still lives in CanvasPaintThread, basically. I also would've preferred to take the reference at the top as soon as I get the CanvasId, since that looks cleaner than having them all start with "canvas_paint_thread.canvases.get_mut[&canvas_id].unwrap()" but that makes trying to take the second reference for DrawImageInOther fail to compile. I'm definitely open to suggestions on how to make that less gross. The timed single-canvas drawing improved in performance from around ~2.2ms to around ~1.7ms. Slither.io runs better and doesn't crash, but I'm not having it crash on my copy from before these changes, so I don't know if that's new behavior or not. --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach build-geckolib` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix #13879 and #10381. <!-- Either: --> - [X] There are tests for these changes (added in the initial steps) <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. --> <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/20680) <!-- Reviewable:end -->
bors-servo
added a commit
that referenced
this issue
Apr 24, 2018
Moved Canvas rendering to a single thread. <!-- Please describe your changes on the following line: --> Implements the "Subsequent Steps" part of the [NCSU Canvas rendering project.](https://github.com/servo/servo/wiki/Canvas-rendering-project) I moved most of the functionality from CanvasPaintThread to CanvasData, so CanvasPaintThread essentially just pulls the info out of the message and calls a method on a particular CanvasData element. I ran into some awkwardness with the fact that one can only take a single mutable reference from a hashmap, though. DrawImageInOther is not really possible to do with only one reference at a time, so it awkwardly still lives in CanvasPaintThread, basically. I also would've preferred to take the reference at the top as soon as I get the CanvasId, since that looks cleaner than having them all start with "canvas_paint_thread.canvases.get_mut[&canvas_id].unwrap()" but that makes trying to take the second reference for DrawImageInOther fail to compile. I'm definitely open to suggestions on how to make that less gross. The timed single-canvas drawing improved in performance from around ~2.2ms to around ~1.7ms. Slither.io runs better and doesn't crash, but I'm not having it crash on my copy from before these changes, so I don't know if that's new behavior or not. --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach build-geckolib` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix #13879 and #10381. <!-- Either: --> - [X] There are tests for these changes (added in the initial steps) <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. --> <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/20680) <!-- Reviewable:end -->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I tried the latest Servo nightly build on Fedora. When I go to http://slither.io/ , I get: