summaryrefslogtreecommitdiffstats
path: root/tests/benchmarks/corelib/tools/qstring
diff options
context:
space:
mode:
authorVolker Hilsheimer <volker.hilsheimer@qt.io>2022-10-01 18:04:56 +0200
committerVolker Hilsheimer <volker.hilsheimer@qt.io>2022-10-03 23:39:23 +0200
commit109e088c7c5d0c9325966e88d55fd9f7a58f67ea (patch)
tree7ad41ed53dfde061cd6417f248d8eb0fe4b88c2f /tests/benchmarks/corelib/tools/qstring
parentf1448b29e3ad4a1b5e1b37f177c9ad83f74e47e7 (diff)
Make sure that palette cache keys are unique
After 1d961491d817490da156769ddce6fce48a0bce4a, palettes are different if they either have different brush data, or a different private. Two privates can share data, but still must generate different cache keys. The cacheKey has so far been composted of the serial number of the Data struct, and a detach number that is incremented when we detach the private. This failed for two reasons: - the implicit copy constructor of the Data class copied the serial number, when it should have incremented it. Fix that by member- initializing the serial number rather than doing it only in the default constructor. The member initialization is also executed for the copy constructor. - the detach_no logic as it was implemented does not guarantee that two copies of the same palette that share data, but have different resolve masks (and thus different privates) have different detach_no values. Use a static serial counter for that number as well. Amend the test case to verfiy that cache keys, and the elements of the cache keys, change when they are expected to. Fixes: QTBUG-106984 Pick-to: 6.2 6.4 Change-Id: I84d7055ce8bfe0d42f1f8e9766f3f1ad610f4ec8 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Diffstat (limited to 'tests/benchmarks/corelib/tools/qstring')
0 files changed, 0 insertions, 0 deletions