Stop raising errors during/after device loss - #4051
Conversation
885c32d to
4b4d25e
Compare
Fixes 4017 Almost completes 1629
4b4d25e to
f9568bd
Compare
toji
left a comment
There was a problem hiding this comment.
LGTM.
It does make me wonder how we should handle the few situations where we throw exceptions, such as validating texture format features. Does the lost device:
- Continue to track which features were enabled to deliver consistent results
- Act as if no features are enabled after the device is lost
- Stop validating the enums all together (which will still be inconsistent across browsers, because the IDL bindings will reject some of them)
In any case, answering that question doesn't stop this change from going into effect.
|
I think content-timeline validation should continue to behave normally, your option 1. It would be kind of artificial to do otherwise, as the content timeline can't even change its behavior until it finds out the device is lost (which is after the time the device is actually lost). The other two options have clear issues (2 can cause exceptions to suddenly start popping up in the middle of the program, and 3 has the problem you observed) |
7615ad6 to
e2db74b
Compare
|
Previews, as seen when this build job started (e2db74b): |
Fixes #4017
One of the last two things to complete #1629