aboutsummaryrefslogtreecommitdiffstats
path: root/src/qmlcompiler/qqmljsfunctioninitializer.cpp
diff options
context:
space:
mode:
authorLaszlo Agocs <laszlo.agocs@qt.io>2021-11-05 14:40:18 +0100
committerLaszlo Agocs <laszlo.agocs@qt.io>2021-11-29 18:40:58 +0100
commit3c7c601a51de1b3de86c995f13cbd56fc6bf76ca (patch)
tree997afe718aec89742936f141eb658e266a7c3f69 /src/qmlcompiler/qqmljsfunctioninitializer.cpp
parenta5ee0ab5555e5a1c0830ecb07028087ad009f146 (diff)
Prevent glyph nodes from draining the update batch pool
Instead of letting each glyph cache instance to borrow its own resource update batch, have a single resource update batch pointer in the rendercontext (so per-thread and per-rhi with the threaded render loop) and reference that in all glyph caches with that rendercontext. This tries to eliminate the problem that occurs when one manages to make more than 64 (texture and/or distance field) glyph caches within the same window. The original mistake was to assume that the glyph cache objects are per-QRhi. This is not the case, the cache key consists of more than that (e.g. with native text: rhi+format+transform+color) While we do not have an actual example, some users have apparently managed to construct scenes where the number of simultaneous glyph caches exceed 64. Note that this might mean that the texture uploads from a glyph caches are not actually merged into the renderer-provided update batch by that cache instance, but by another one (depending on the order of commit calls during sync, the first one gets to submit all enqueued uploads). This should be ok because all that matters it that the upload requests end up in the renderer's update batch in one way or another. Pick-to: 6.2 Fixes: QTBUG-98017 Change-Id: I988d568377aa9766457ab02e070220e8a76ddbaf Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Diffstat (limited to 'src/qmlcompiler/qqmljsfunctioninitializer.cpp')
0 files changed, 0 insertions, 0 deletions