* Use 2024 style edition
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
* Reformat all code
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
---------
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
* ohos: Remove unnecessary library links
`ohos-sys` now correctly links all required libraries, so we
don't need to specify them here again.
We still specify `ace_napi.z`, since we use napi via `napi-ohos`, which currently does not add the required link.
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
* Disable some unused functions on ohos/android
- get_default_url()
- parse_url_or_filename()
- add_noto_fallback_families
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
* ohos: Remove unneeded import
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
---------
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
System fonts used to be instantiated using the system font loader and
this change restores that behavior. In addition, on macOS and FreeType
platforms font data for system fonts is loaded using memory mapping. The
benefit is that system font loaders typically are able to cache fonts in
system memory (using memory mapping, for instance) and we'd like to load
them in a the way most compatible with other applications.
On my Linux system, this manages to get the overhead of loading a very
large font down from 10ms to approximately 1ms. Subsequent runs show
even less overhead. We've measured similar gains on macOS systems.
Currently, system font data must be loaded into memory manually for
canvas and this is unlikely to change even with a switch to `vello`. The
use of explicit memmory mapping should help in this case -- though it
probably won't be possible to use this properly on macOS and Windows if
we ever want to load fonts from TTCs properly.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com>
* ohos: Add `ohos_mock` cfg.
This allows using the Linux build together with the `ohos`
font code, using the fonts ship in the `previewer` directory of the OH SDK.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
* ohos: Detect installed fonts
Scan the systems font folder to detect installed fonts,
derive their associated font names and generate the font list
based on that.
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
* Use hardcoded filepaths for HMOS Color emojis
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
* Also support parsing OH 4.x Noto fonts
Currently we don't have an easy way to test the OH version
from the fonts module, so the parsing code has to be extended.
Once the OH 5.0 beta has a reliable fontconfig.json filemap,
then we can probably get rid of most of the parsing code,
and hardcode the OH 4.x Note fonts as a fallback.
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
This crate only takes care of fonts now as graphics related things are
split into other crates. In addition, this exposes data structures at
the top of the crate, hiding the implementation details and making it
simpler to import them.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com>
2024-06-19 20:26:19 +00:00
Renamed from components/gfx/platform/mod.rs (Browse further)
