Bug 66742
| Summary: | Write regression test for WebGL rate limiting | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | John Bates <jbates> |
| Component: | WebGL | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED CONFIGURATION CHANGED | ||
| Severity: | Enhancement | CC: | darin, kbr, kkinnunen, nduca |
| Priority: | P3 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
John Bates
Write regression test for bug fix: https://bugs.webkit.org/show_bug.cgi?id=66445.
This would test whether the WebGL rate limiting is properly executing. We would want to test both RAF and non-RAF use cases. In non-RAF cases, test that rate limiting kicks in only when it is supposed to.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Kenneth Russell
I've changed the component to WebGL so that it shows up easily on searches.
Nat Duca
There really are two things to veirfy here: that WebGLLayerChromium behaves correctly when dirtied outside of RAF, and that WebGLGraphicsContexts call setLayerUpdated.
At least for the latter case, mock testing might be a more appropriate vehicle for testing.
Mock could be: instantiate a compositor tree with a WebGLLayerChromium. Fire commands onto the webglcontext outside of the render task and assert that the ratelimiting task gets called on that context.
Nat Duca
Might be good use case of frame rate tests on chromium-side.