When NativeRendering is used, we keep a reference to all the font
engines currently in use to make sure they stay alive, and then
dereference them when the scenegraph is invalidated, typically when
the window closes.

There was always a controlled leak here: If you loaded new font assets
continuously, then we would retain the old ones in memory. Due to
the bug in QTBUG-100697, we would keep them even if they were
application fonts that were removed.

However, when QTBUG-100697 was fixed, a side effect was that the memory
leak became more visible: It no longer only happens when loading new
fonts, but just loading and unloading the same two application fonts
and setting them on a text item in a loop would cause us to
continuously create new font engines, give them a font cache and then add
them to the m_fontEnginesToClean list.

The fix is to match the registerFontEngineToClean() with an unregister
function and then clean up the font engines that no longer have any
references during the synchronization step, similar to how we clean
up distance field caches that are no longer in use.

Note that this removes a bogus qDeleteAll() from the software backend:
This was added blindly by f1b188df132c42da62197055725e5f7eebcc4249.
Since the set will be empty, it doesn't cause a crash, but is not the
correct way to delete font engines, so to avoid future confusion or
cargo-culting, we just replace it with an assert that the set is
empty.

[ChangeLog][Text] Fixed a controlled memory leak with Text.NativeRendering
where loading and unloading the same application fonts could cause memory
usage to increase indefinitely and not be regained until the window was
closed.

Fixes: QTBUG-113714
Change-Id: I34c60e647bf63a0d203f752066f1cbfaeb049bcf
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit eed2ee69ac291da33c48093bc2c2bc4d359f46a2)

The glyph cache key is based on the RHI instance. We clean up the font
cache when the QSGRenderContext is deleted.

For a regular QQuickWindow this is effectively the same. For a
QQuickWidget the RHI instance has a lifespan of the parent widget, but
the render context changes.

Task-number: QTBUG-113426
Task-number: QTBUG-112306
Change-Id: Ifd901ace6caaff9a08352901956865f5f58e06ef
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit cc4fbbc5ef208ef22c94b1b034173edffacafe19)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>

Move the management of the to-be-released textures up to the
rendercontext, so that the glyph cache objects do not need to
care about this. Issuing a delete(Later) on the QRhiTexture in
the glyph cache is too early if there is no visible text item
in the scene that's going to commit the resource updates
collected on the rendercontext's QRhiResourceUpdateBatch.
Instead, it is logical to move also the list of pending-release
textures to the rendercontext, since it already has the update
batch object.

Fixes: QTBUG-111995
Change-Id: Ic4309166f265950a7061ae510567ce677c4943df
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
(cherry picked from commit e9c0b15060e0b70f70857d02029d6ebed95c0abf)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>

Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.

Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>

Change-Id: I517d317ea9d1b01ef9366999de71e62256a6230f
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>

Change-Id: I1e52743937a4dd7bdebf0b03d3c0ecd1169a9558
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

One set of functions is enough, no need for a separate set of "Rhi"
ones.

Change-Id: I58600c539734d5f8a767926eb9649d9968bab08a
Reviewed-by: Christian Strømme <christian.stromme@qt.io>

Add QQuickRenderTarget::fromPaintDevice, aollow to get a
QQuickRendererTarget from the QPaintDevice object.

[ChangeLog][QtQuick] Added QQuickRenderTarget::fromPaintDevice,
Allowed to set the render target of QQuickWindow on the software
renderer.

Task-number: QTBUG-94075
Change-Id: I4946c25d2a6315cd8f9c12a7ac7ac4cf71d95361
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>

We had multiple related issues due to application fonts being added
or removed during the application lifetime.

1. If a text had font family "foo" set, and this font did not
exist at the time, then loading "foo" at a later stage would not
update the text to use the correct font, since the result of
the previous request had been cached.

2. A variation of #1 was if the font "foo" was loaded by a FontLoader
in the scene and referred to by name in the text component. In this
case, there was a race condition, where the font lookup would sometimes
yield different results on the main thread and on the render thread,
and text would be garbled.

3. When a font was removed from the font database, then references to
it would remain in the caches (glyph cache + font cache) in the render
thread. With certain backends (DirectWrite, CoreText) this caused errors
or even crashes, as the cached font engines would be referring to data
that had been removed.

The work-around for #1 and #2 was merely to avoid hardcoding names for
fonts, but instead getting them from the FontLoader. This way, you can
avoid requesting the font family before it is available (and thus avoid
caching the wrong result). However, for #3 there is no known work-around.

This patch fixes all three (together with a smaller patch for qtbase) by
invalidating all text and related caches in Qt Quick when fonts are
either added or removed from the font database. This does add some
overhead if font loading happens during runtime, but the alternative is
broken behavior and dangling pointers.

This is done during the synchronization step. Before synchronization,
the font cache is flushed and all text components are marked for update,
so that fonts are re-requested against the new font database.

After synchronization, we delete all distance field glyph caches which
are not currently in use, to avoid having references to stale application
font data in the list.

[ChangeLog][Text] Fix multiple issues with usage of application fonts when
they are added or removed during the lifetime of the application.

Task-number: QTBUG-100697
Task-number: QDS-1142
Change-Id: Ib309e54e0ee97b6be6d2a7211964043fd51c9ec5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>

The flag has been unconditionally set to true since Qt 6.0.

Change-Id: Ie6ad91f00b5c7ac7d6a7745035175f23c9641a42
Reviewed-by: Hatem ElKharashy <hatem.elkharashy@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>