diff options
| author | Laszlo Agocs <laszlo.agocs@qt.io> | 2021-11-05 14:40:18 +0100 |
|---|---|---|
| committer | Laszlo Agocs <laszlo.agocs@qt.io> | 2021-11-29 18:40:58 +0100 |
| commit | 3c7c601a51de1b3de86c995f13cbd56fc6bf76ca (patch) | |
| tree | 997afe718aec89742936f141eb658e266a7c3f69 /src/qmlcompiler/qqmljsfunctioninitializer.cpp | |
| parent | a5ee0ab5555e5a1c0830ecb07028087ad009f146 (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
