-
Task
-
Resolution: Unresolved
-
P2: Important
-
6.2
Image providers are currently stored in the QML engine, which is most likely the wrong place, considering that images are inherently graphical while the engine can be used in a non-UI context. A better place for the image providers might be QQuickWindow.
We'd also like to have a replacement for QQmlEngine::addImageProvider, as that leads often to non-optional plugins: If a QML module wants to register an image provider, it has to call addImageProvider, for which it needs an engine pointer. The only way to obtain that pointer is by writing a plugin, with a custom initializeEngine method. As that plugin does more than registering types, it cannot be optional.
Maybe we need to mirror QML singletons, and provide a way to register a factory function. Then the engine could trigger the creation of the providers on-demand – though that raises the question where to store the factory functions.
We also need to investigate thread-safety:
1) Is it currently possible to share the same image provider among multiple engines?
2) If yes, does that actually work, or do we just get lucky when it comes to race conditions.
- blocks
-
QTBUG-105651 Add image providers automatically with modules
-
- Reported
-
- depends on
-
QTBUG-108146 move remote resource loading from Qt Quick to QtCore
-
- Reported
-
- duplicates
-
QTBUG-90627 Research a better PixmapCache <-> Image Provider interaction
-
- Open
-
- is required for
-
QTBUG-106835 qmltc: support ImageProviders
-
- Reported
-
- relates to
-
QTBUG-81266 figure out whether QPixmapCache and QQuickPixmapCache can be unified
-
- Reported
-
-
QTBUG-111036 Decide what the QML Plugin Example should demonstrate
-
- Reported
-
-
QTBUG-135814 Make it easier to implement (and get guidance for) statically-linked, custom-defined QQmlEngineExtensionPlugin
-
- Reported
-
- mentioned in
-
Page Loading...