We can reduce code size and complexity by completely eliminating the prepare-to-serialize step of bindings serialization, which is currently used to collect handles.

This step imposes complexity on typemapping code as well as requiring SerializationContext to maintain a dynamic "null state" vector to which the serialization phase can then refer. For one example of extra subtelty here, typemaps which map a field that's an array of handles still cannot actually make the guarantee that their accessor is called only once.

We can support augmenting message objects with additional handles in a way that only incurs a single extra allocation during serialization regardless of the number of handle attachment API calls.


For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

 

We can reduce code size and complexity by completely eliminating the prepare-to-serialize step of bindings serialization, which is currently used to collect handles.

This step imposes complexity on typemapping code as well as requiring SerializationContext to maintain a dynamic "null state" vector to which the serialization phase can then refer. For one example of extra subtelty here, typemaps which map a field that's an array of handles still cannot actually make the guarantee that their accessor is called only once.

We can support augmenting message objects with additional handles in a way that only incurs a single extra allocation during serialization regardless of the number of handle attachment API calls.