Synchronize title/background/etc. once when the window is mapped and
afterwards lazily when the corresponding property tracker notifies us.
Since that callback can happen at any point in time and to also capture
potentially multiple changes, this first triggers a wakeup of the event
loop, when the actual application of properties happens.
By default PropertyTracker::evaluate() registers the currently
evaluating binding/tracker as a dependency. This should help with
repeaters and other scenarios where in the run-time we use property
trackers but want to track the overall "dirtyness" in the window with
regards to whether a redraw is needed or not.
The new evaluate_as_dependency_root() function allows skipping this
mechanism and is used for the two trackers in the window.
Try adding an LC_RPATH command to the cdylib that we're building (for example libsixtyfps_cpp.dylib),
to fix linkage against Qt, which uses `@rpath/QtCore.framework/XXX` for inter-library linkage dependencies.
Remove the `application` infix from `register_application_font`, to
reduce the changes that it might be interpreted to be a function that
also changes the default font in all text elements.
Since colorize property force the native item to be a ClippedImage, it had
a source rectangle, despite with and height defaulting to 0 and therefore
having an empty source rect would cause the scaling to not be right
Have a function first called before the children, and then the main function
called after the children if they did not accept the event. This will allow
processing the Flickable gesture properly
Remove the pos parameter to the render functions and instead let
the item renderer apply the transformation on the rendere (femtovg
canvas or QPainter).
So `draw_*` functions in the backend now always operate in item local
coordinates.
Commit 8a66af0746 resulted in pending html
images not being strongly referenced anymore through the item's
rendering cache when first queried in the image size query. That means
they initially reported a size (1x1) and after loading they *should*
mark the bindings dirty that depend on the implicit size, but since the
image was deleted (and along with it the notifying property), the image
kept its visible (1x1) size.
Similarly, images would get loaded too much from disk - same cause,
different effect.
To fix this, go back to the earlier design where the renderer's image
cache keeps a strong reference.
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.
