[worklets] Allow long running scripts to be informed that they are being treated as unresponsive? #507
Labels
Comments
|
This came up in the context of testing the behaviour of unresponsive scripts, but may come up in other contexts too. servo/servo#17370 |
|
I guess throw an error at window? I think that's been used for similar things. |
|
Or at the element which has the worklet attached to it? |
|
The Working Group just discussed
The full IRC log of that discussion<TabAtkins> Topic: Unresponsive scripts<TabAtkins> github: https://github.com//issues/507 <TabAtkins> iank_: Curreently the spec text allows a while(true) loop, the UA can kill it whenever. <TabAtkins> iank_: But no feedback to the dev, nothing throws. <TabAtkins> iank_: Do we want to notify th edev? <TabAtkins> iank_: So an error fired on the Worklet object (in the main thread), perhaps? <TabAtkins> iank_: Or punt to l2 <TabAtkins> smfr: Specific to paint worklets? <TabAtkins> iank_: All worklets <TabAtkins> surma: I think at the start, dev tooling is good enough, no need to require it yet <TabAtkins> Rossen: We can kick it down the road <TabAtkins> iank_: That' my impression too. <TabAtkins> dbaron: Should we tag this as for worklets spec, not paint api? <TabAtkins> iank_: yES <TabAtkins> RESOLVED: Punt slow-script dev notification to level 2 of worklets |
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Nov 16, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
5 tasks
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Nov 25, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Nov 25, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Nov 25, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Nov 27, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Nov 28, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Dec 16, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Dec 18, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Dec 18, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. Since we did not have a better way to trigger a timeout than a busy waiting loop (which would hog one core of the test machine until the timeout was reached), we decided to implement a test only blocking sleep, available to the PaintWorkletGlobalScope. Since `dom.worklet.enabled` enables worklets in general, we also decided to have another pref `dom.worklet.blockingsleep.enabled`, which, in addition to `dom.worklet.enabled`, would be required for the blocking sleep to be available. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Dec 19, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. Since we did not have a better way to trigger a timeout than a busy waiting loop (which would hog one core of the test machine until the timeout was reached), we decided to implement a test only blocking sleep, available to the PaintWorkletGlobalScope. Since `dom.worklet.enabled` enables worklets in general, we also decided to have another pref `dom.worklet.blockingsleep.enabled`, which, in addition to `dom.worklet.enabled`, would be required for the blocking sleep to be available. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Dec 19, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. Since we did not have a better way to trigger a timeout than a busy waiting loop (which would hog one core of the test machine until the timeout was reached), we decided to implement a test only blocking sleep, available to the PaintWorkletGlobalScope. Since `dom.worklet.enabled` enables worklets in general, we also decided to have another pref `dom.worklet.blockingsleep.enabled`, which, in addition to `dom.worklet.enabled`, would be required for the blocking sleep to be available. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
bors-servo
pushed a commit
to servo/servo
that referenced
this issue
Dec 22, 2017
Paint worklets: Implement timeout for worklet painter threads When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering at 60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes #17370. [1]: w3c/css-houdini-drafts#507 <!-- Please describe your changes on the following line: --> --- <!-- 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 test-tidy` does not report any errors - [x] These changes fix #__ (github issue number if applicable). <!-- Either: --> - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- 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/19256) <!-- Reviewable:end -->
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Dec 22, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. Since we did not have a better way to trigger a timeout than a busy waiting loop (which would hog one core of the test machine until the timeout was reached), we decided to implement a test only blocking sleep, available to the PaintWorkletGlobalScope. Since `dom.worklet.enabled` enables worklets in general, we also decided to have another pref `dom.worklet.blockingsleep.enabled`, which, in addition to `dom.worklet.enabled`, would be required for the blocking sleep to be available. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Dec 22, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. Since we did not have a better way to trigger a timeout than a busy waiting loop (which would hog one core of the test machine until the timeout was reached), we decided to implement a test only blocking sleep, available to the PaintWorkletGlobalScope. Since `dom.worklet.enabled` enables worklets in general, we also decided to have another pref `dom.worklet.blockingsleep.enabled`, which, in addition to `dom.worklet.enabled`, would be required for the blocking sleep to be available. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
yati-sagade
added a commit
to yati-sagade/servo
that referenced
this issue
Dec 22, 2017
When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering @60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the `dom.worklet.timeout_ms` pref. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. Since we did not have a better way to trigger a timeout than a busy waiting loop (which would hog one core of the test machine until the timeout was reached), we decided to implement a test only blocking sleep, available to the PaintWorkletGlobalScope. Since `dom.worklet.enabled` enables worklets in general, we also decided to have another pref `dom.worklet.blockingsleep.enabled`, which, in addition to `dom.worklet.enabled`, would be required for the blocking sleep to be available. This fixes servo#17370. [1]: w3c/css-houdini-drafts#507
bors-servo
pushed a commit
to servo/servo
that referenced
this issue
Dec 22, 2017
Paint worklets: Implement timeout for worklet painter threads When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering at 60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes #17370. [1]: w3c/css-houdini-drafts#507 <!-- Please describe your changes on the following line: --> --- <!-- 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 test-tidy` does not report any errors - [x] These changes fix #__ (github issue number if applicable). <!-- Either: --> - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- 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/19256) <!-- Reviewable:end -->
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Dec 22, 2017
…ainter threads (from yati-sagade:master); r=asajeffrey When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering at 60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes #17370. [1]: w3c/css-houdini-drafts#507 <!-- Please describe your changes on the following line: --> --- <!-- 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 test-tidy` does not report any errors - [x] These changes fix #__ (github issue number if applicable). <!-- Either: --> - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- 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. --> Source-Repo: https://github.com/servo/servo Source-Revision: 54f8cc37c5a7874607128e3518fd0982f7065565 --HG-- extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear extra : subtree_revision : 0234a7fd5437d1c2a9c0424b9e2bb51d309a4490
xeonchen
pushed a commit
to xeonchen/gecko-cinnabar
that referenced
this issue
Dec 23, 2017
…ainter threads (from yati-sagade:master); r=asajeffrey When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering at 60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes #17370. [1]: w3c/css-houdini-drafts#507 <!-- Please describe your changes on the following line: --> --- <!-- 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 test-tidy` does not report any errors - [x] These changes fix #__ (github issue number if applicable). <!-- Either: --> - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- 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. --> Source-Repo: https://github.com/servo/servo Source-Revision: 54f8cc37c5a7874607128e3518fd0982f7065565
bfgeek
changed the title
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified-and-comments-removed
that referenced
this issue
Oct 2, 2019
…ainter threads (from yati-sagade:master); r=asajeffrey When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering at 60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes #17370. [1]: w3c/css-houdini-drafts#507 <!-- Please describe your changes on the following line: --> --- <!-- 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 test-tidy` does not report any errors - [x] These changes fix #__ (github issue number if applicable). <!-- Either: --> - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- 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. --> Source-Repo: https://github.com/servo/servo Source-Revision: 54f8cc37c5a7874607128e3518fd0982f7065565 UltraBlame original commit: 917173512a567ac19442db3b18afa983c93d725f
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-comments-removed
that referenced
this issue
Oct 2, 2019
…ainter threads (from yati-sagade:master); r=asajeffrey When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering at 60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes #17370. [1]: w3c/css-houdini-drafts#507 <!-- Please describe your changes on the following line: --> --- <!-- 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 test-tidy` does not report any errors - [x] These changes fix #__ (github issue number if applicable). <!-- Either: --> - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- 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. --> Source-Repo: https://github.com/servo/servo Source-Revision: 54f8cc37c5a7874607128e3518fd0982f7065565 UltraBlame original commit: 917173512a567ac19442db3b18afa983c93d725f
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified
that referenced
this issue
Oct 2, 2019
…ainter threads (from yati-sagade:master); r=asajeffrey When a paint worklet thread takes too long, we would like to move on, since we have a ~16ms budget for rendering at 60fps. At the moment, there is no provision in the paintworklet spec to signal such timeouts to the developer. ajeffrey opened an [issue][1] for this, but it got punted to v2 of the spec. Hence we are silently timing out unresponsive paint scripts. The timeout value is chosen to be 10ms by default, and can be overridden by setting the SERVO_PAINT_WORKLET_TIMEOUT_MS environment variable. In the absence of such a timeout, the reftest in this commit would fail by timing out the testrunner itself, since the paint script never returns. From my discussions with ajeffrey, this should do until we spec out a way to signal timeouts to the script developer. This fixes #17370. [1]: w3c/css-houdini-drafts#507 <!-- Please describe your changes on the following line: --> --- <!-- 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 test-tidy` does not report any errors - [x] These changes fix #__ (github issue number if applicable). <!-- Either: --> - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- 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. --> Source-Repo: https://github.com/servo/servo Source-Revision: 54f8cc37c5a7874607128e3518fd0982f7065565 UltraBlame original commit: 917173512a567ac19442db3b18afa983c93d725f
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
In https://www.w3.org/TR/css-paint-api-1/#drawing-an-image, there is a note
This provides user and developer feedback in the UI, but does not inform the script that the UA is considering it to be unresponsive. Should unresponsive scripts be informed that they are unresponsive?
The text was updated successfully, but these errors were encountered: