This requires the image size query to be window independent and go
through the backend instead.
This implies minor changes for the Qt backend and bigger ones for the GL
backend:
* There exists now a thread-local IMAGE_CACHE, which is used by the
backend's image_size() function as well as by the renderer for
loading CPU side images.
* The image remain as decoded images in there (including SVG tree)
and the window now has a texture_cache, which holds CachedImage
with ImageData::Texture.
* Rendering an image item therefore fetches the CPU side image,
calls upload_to_gpu() on it, which creates a new Rc<CachedImage>
and that's stored in the texture_cache.
* The texture cache continues to be pruned when hiding the window.
Test that assigning colors works:
* Test the implicit `Brush(const Color &)` C++ constructor
* Add derive_more::From to allow convenient conversion in Rust
* When assigning to brush properties in JavaScript, try at least to see if it's a color string (could be extended in the future)
Use only specific lyon packages instead of pulling all of them in.
This slightly speeds up compilation as well as for example lyon_tesselation
doesn't need to be compiled anymore.
Allow converting a brush to a color. In the case of a gradient, the color of the first stop is returned.
For the C++ generator this requires adding the extra case of explicitly
calling the `Brush(const Color &)` constructor, despite it being implicit,
in order to generate the correct code when we have IR that casts twice:
```
Expression::Cast {
from: Expression::Cast {
from: Expression::Cast {
from: Expression::NumberLiteral(...),
to: Type::Color,
}
to: Type::Brush,
},
to: Type::Color,
}
```
* Always apply a transformation (less variants)
* Let the path data iterator take ownership of the data. That will
make it possible to return a PathDataIterator from a function in the
future
We're going to need support for InterpolatedValue, which at the moment
has trait requirements that are a bit too tight.
It's sufficient if it takes references to values and doesn't require Copy or Clone.
The latter can go into the bounds where it's actually used.
A few changes were required:
* `LinearGradient(LinearGradient)` as enum variant unfortunately
won't compile because the cbindgen generated constructor
function (`LinearGradient()`) will try to also instantiate the
variant type inside (`LinearGradient`) and that won't find the type
but the function itself and error out. So the inner type is now
called `LinearGradientBrush`.
* The same name dance was required for `Color`, where the enum variant
instead is called `SolidColor`
* `BrushInner` was removed in favor of just `Brush`. The nicer Rust
API will be the public variant, and for cbindgen we can just put
the generated enum into an internal namespace, like we do for
Resource for example
* A `NoBrush` variant was added. Maybe that name could be improved?
