[impeller] OpenGL ES: Refactor handle table and debug label management. #33598
Conversation
Acquires fewer locks and doesn't throw GL errors when setting labels on create-on-bind resources that haven't been bound yet. In such cases, the label will be set on the next reaction.
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
Handle management in the reactor is now fully thread safe and setting debug labels doesn't need a check to ensure that create-on-bind resources have actually been bound before. OpenGL errors are now back to being fatal errors instead of merely logging. |
chinmaygarde
force-pushed
the
better_handle_table
branch
from
96b5bb8 to
e9e3a7b
Compare
zanderso
left a comment
zanderso
left a comment
There was a problem hiding this comment.
Are there any tests that can be written for this change, or is it a pure refactor?
|
Right now, it is just a pure refactor. Though just a unit-tests harness for the reactor and other components in the ESn backend makes sense. These components just don't need to exist in Metal and so parameterizing the existing tests for Open GL probably doesn't tickle these in a way I'd consider thorough. I'll add a separate harness for just for ES. |
…t. (flutter#33598) Acquires fewer locks and doesn't throw GL errors when setting labels on create-on-bind resources that haven't been bound yet. In such cases, the label will be set on the next reaction.
2 participants
Acquires fewer locks and doesn't throw GL errors when setting labels on
create-on-bind resources that haven't been bound yet. In such cases, the
label will be set on the next reaction.