- Guards against duplicate activations by checking wether the backend of the prior scope is the same as the current ones
- Makes sure that only the most outer backend scope deactivates by tracking activation state
- Guards against duplicate activations by checking wether the backend of the prior scope is the same as the current ones
- Makes sure that only the most outer backend scope deactivates by tracking activation state
These changes are necessary for programs whose set of active attributes is not fixed at compile time by a template parameter pack, but rather varies based on the generated shader text at runtime. In such cases, the attribute location of a given named attribute may vary between instances of the same Program.
Previously, attribute bindings were implicitly associated with a location based on template parameter order, and -1 was used to indicate an inactive attribute. This left us unable to disable the appropriate attribute when it went from active to inactive. Now, the state tracker for bindings explicitly associates locations and state, and an empty optional is used to indicate an inactive attribute.
In addition, a gl::VertexArray class is now exposed, allowing more flexibility in the relationship between Programs, Segments, and attribute bindings. In this commit, that relationship does not change, but the subsequent commit adjusts it to match gl-js, reduce rebinds, and work around buggy VAO implementations.
VertexArray uses a pimpl idiom in order to support implementations that lack the VAO extension. In that case, all VertexArrays share global binding state, reflecting the platform reality in the absence of VAOs, while still providing a uniform API.
Introducing two new attributes to enable property functions for line-width (#9250) pushed the attribute count over GL_MAX_VERTEX_ATTRIBS on some devices. Now we selectively bind only attributes that are used, making it unlikely to surpass GL_MAX_VERTEX_ATTRIBS.
The current value is not passed to `SymbolSizeBinder::uniformValues`, so we shouldn't check `currentValue.isConstant()` in `SymbolSizeBinder::attributeBindings`. If it were true, then we might end up using attribute bindings that are appropriate only for a constant property, but uniform bindings that are appropriate only for a source or composite function.
Instead, just wait for a new bucket to be generated. This will happen automatically, since icon/text-size are layout properties.
