Yati Sagade aa48a2c2e3 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 @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 #17370. [1]: https://github.com/w3c/css-houdini-drafts/issues/507		2017-12-22 10:47:23 +01:00
..
Cargo.toml	Update euclid, azure, skia, offscreen_gl_context, plane-split, webrender	2017-12-08 14:32:28 +01:00
lib.rs	Paint worklets: Implement timeout for worklet painter threads	2017-12-22 10:47:23 +01:00
script_msg.rs	Revert "Send IPC receiver for canvas as part of CreateCanvasPaintThread message"	2017-12-18 10:51:00 -05:00
webdriver_msg.rs	Bump euclid to 0.14.	2017-06-14 16:00:59 +02:00