Don't use the item's rendering cache to determine the image size, as
that's soley for rendering. The Qt backend doesn't use the item cache
and the GL backend neither after this change. Instead both backends have
a cache for decoded images.
This allows creating multiple windows for example, and it will allow for
showing windows in those tests that require a mapped window.
As a bonus, the run() function on generated components is not consuming
anymore.
Reduce the dependency of the GLRenderer to a new trait that exposes the
EventLoopTarget and EventLoopProxy. Those are provided by either an
winit::event_loop::EventLoop or, once the loop is started using the
self-consuming run(), by the event loop target provided to the run_fn.
This way renderers can be created from either within run or before.
The initial event loop instance is kept in TLS. When starting the loop,
it's taken out and instead the event loop target is placed into a scoped
tls variable.
During rendering the GLRenderer's Option<WindowedContext<NotCurrent>>
is None. That however leads to any font_metrics() calls such as due to
implicit sizing to panic, because the call requires access to the
window's scale factor.
This is fixed by keeping a shared reference to the PossiblyCurrent
WindowedContext also in the GLRenderer.
The GL backend uses the item graphics cache for the image size function,
which uses a PropertyTracker. That tracker must have the Image's source
included in its dependencies, to avoid that when loading a HTML image
for example, the cache isn't invalidated when the source is changed
before the HTML image was loaded async. That's why the get() call on the
source property must happen from within the PropertyTracker's callback.
For all other items the default is the empty size.
This also required three fixes for the HTML image loading:
* The upload_pending property value was inverted, it needs to start
out as true (pending yes) and be set to false when it finished
loading (not pending anymore)
* Mark the upload_pending property as dirty before scheduling the
redraw, in case it's sync
* Pass the item rendering cache to the image_size function to ensure
that the Rc<CachedImage> is not only weak inside the image_cache
of the GLRendererData but also strong on the item.
Allow images to be just decoded and uploaded to the GPU in a separate
step. This is in preparation to implicit size support, where the actual
dimension of the image can be determined by decoding it immediately when
needed and uploaded to the GPU later (when we can be sure to have a
current GL context).
For images loaded through HTMLImageElement this is trickier, in the
sense that - unlike when loading off disk - it is inherently async.
Therefore we use a Property<bool> that we toggle when loading is
complete, in order to mark any dependent bindings as dirty, after
reporting an initial (1, 1) size.
Move data structures shared between the GLRenderer and the
GLItemRenderer into a *ka-ching* shared data structure. This reduces the
amount of separate Rc instances.
Also moving the image loading functions from GLItemRenderer to
GLRendererData will allow for re-use from the GLRenderer in the future.
For the GL backend a resolved font is just a handle (femtovg::FontId)
and we can cache that. Consequently we don't really need Rc<dyn Font>
but can let `fn font(...)` on the backend return a "resolved" font that
includes the pixel size, which in turn simplifies the Font trait
signatures.
The only caveat is that because on the item level we don't know what the
chosen backend type is, we can only receive a `dyn Font`, which means
it's wrapped - for now - in a Box.
* When calculating the height of text for vertical alignment purposes,
don't use the minimum height but stick to ascent + descent - like the old
renderer. This gives Text items a constant height that depends on the
font size and not the content.
* Avoid scaling text metrics twice. It turns out that femtovg uses the
device pixel ratio / dpi argument for `set_size` only for scaling text
metrics. Since we do all the mapping from logical pixels to physical pixels
it's correct to let femto only operate in physical pixel range. As a bonus
this allows removing the refresh_window_scale_factor() dance in the
backend (including making the context current, etc.)
