7e2cef0f15
...but keep support for deserializing for all older versions in order to play nice with existing .qsb files. The usage of binary JSON and then CBOR is a historical artifact: relying on the QJsonDocument (which we generate for purposes unrelated to binary serialization) was a convenient shortcut. However, writing to and reading from a QDataStream instead (which QShader already does) is trivial. In order not to be limited by potential CBOR requirements in the future, take it all into our own hands. Extend the qshader autotest accordingly. Task-number: QTBUG-81298 Change-Id: If0047b659bd6601ca47b5bbbce1b719630cde01e Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io> |
||
|---|---|---|
| .. | ||
| color_all_v1.vert.qsb | ||
| color_spirv_v1.vert.qsb | ||
| color.vert | ||
| README | ||
| texture_all_v2.frag.qsb | ||
| texture_all_v3.frag.qsb | ||
| texture_all_v4.frag.qsb | ||
| texture.frag | ||
Warning: Do NOT regenerate the .qsb files without proper planning and understanding the following. Among other things, we are also testing backwards compatibility for QShader deserialization. .qsb files with _v1 in the name were produced with an older qtshadertools and have a QSB_VERSION of 1. Files with _v2 are generated with a newer qsb, those have QSB_VERSION 2. The difference is the support for nativeResourceBindingMap() which is only present in v2. Files with _v3 come from an even newer qsb, and have QSB_VERSION 3. The difference to 2 is the use of CBOR instead of binary JSON for QShaderDescription.