It is not deterministic relative to the time it takes to update the properties,
currently in some cases properties may be updated before `sourceChanged()` is
emitted and in some cases not, depending on the pace of the rendering and the
rendering thread.
If we signal the change immediately after the source changes, we don't have
this problem.
Currently this is asymptomatic, but better to correct it.
This is mostly relevant when the new source is null (no more source),
since if there is a new source the properties would be updated in
most cases in 1/FPS, if everything goes well, provided that the new
source is a texture provider.
Even if the target is a layer and has rapidly changing size,
due to resize or other reasons, the comparison key remains
the same. For that reason, it is safe to have a notify
signal for this property.
In Qt versions older than 6.6, this allows making use of rhi. One
may argue that this is risky to do, considering that there is
already a fallback mechanism that does not use rhi, however we
only use `QRhiTexture::pixelSize()` here which is not expected
to change any time soon.
I have tested this with Qt 6.2. This change effectively enables
using rhi to probe the native texture size for all Qt versions
we support, provided that gui-private is available. Some
distributions such as Debian provide it in a different package.
Currently we are not enforcing availability of Qt gui-private,
unless it is used for some functionality (for example video
integration). So, we still need to keep the legacy fallback
option here.
The source item and window may change and thus deviate from the captured
ones before the window starts synchronizing in the current or the next
frame (depending on what the stage is currently).
This is to see if the source texture provider actually
provides a texture, and especially useful if it is
important to know when the texture would be available.
One particular use case for this is with static effects,
such that it makes it possible to apply the effect once
the source provider starts providing the texture.
`Image` as texture provider has `Image.Ready` status,
but it seems that it is not really the best reflection
for whether the texture is ready or not. My understanding
is that it is rather for when the image is loaded, and
not necessarily the texture.
As the name suggests, this makes it possible to introspect
whether the source texture has an alpha channel or not.
This is mostly relevant for non-layer textures, as it seems
that layers always have an alpha channel.
Instead of event based approach, it now uses sampling based
approach, like we have done in high precision timer widget
before (389a1999).
I also started using `std::atomic` instead of `QMutex`.
This is comparable to `textureSize()` in GLSL, it provides the
native texture size as opposed to the scene graph texture size
which returns the sub-texture size, be it an arbitrary sub-
texture or atlas texture.
Fatih Uzunoglu