[pull] master from libass:master #43
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As far as I can tell, this is completely unused in VSFilter.
This emulates GDI's behavior, both around scoring and faux decisions. The fontconfig provider doesn't provide the full information we'd need to handle this 100% accurately, so it's best-guessed.
Coefficient derived experimentally.
This release brings optimized assembly routines for aarch64, as well as numerous individual improvements and fixes. Furthermore, Meson/muon is added as a secondary build system restoring first-party support for MSVC builds. Note however, this build setup is not at feature parity with autotools and in particular not considered suitable for packaging purposes on non-Windows platforms. For more details see our README.
For all changed occurrences it makes no difference wrt to the allocated memory, but modern compilers started to print warnings
Corresponds to upstream https://code.videolan.org/videolan/x86inc.asm/-/commit/b6ba1e3045d758fd6c6e24591dac21a3dc812e1d This obsoletes our custom patch for 64-bit Haiku checkasm
This reverts commit 0a63b95. The issue was fixed more broadly in upstream x86inc.asm with https://code.videolan.org/videolan/x86inc.asm/-/commit/b6ba1e3045d758fd6c6e24591dac21a3dc812e1d
The list is now maintained at https://github.com/libass/libass/wiki/Projects-using-libass
Since active'ish forks focus on internal use, they might not appreciate getting potential external users prominently redirected their way, so do not link them atm. Should they expand scope we can add links later.
This makes the code easier to follow and avoids a bogus warning about unitialised use of add_separator (due to the initial assert this could never happen).
We pass data read from the pattern to fontselect and keep it referenced until fontselect is destroyed. This currently works due to all patterns coming from the config and being referenced there too, but let’s make it explicit.
With the preceding commit all providers implement this now.
The full system font list we used before is not guaranteed to be sorted by any meaningful criterion. Additionally fontconfig doesn’t distinguish between different kinds of family name, in particular also returning e.g. "Noto Sans" for "Noto Sans Condensed". Since width is not a criterion in ASS font selection and accordingly was removed from our logic in 3f153be. This means related font family of different widths may end up reporting one overlapping family name and tie on scoring, resulting in whatever was listed first being selected. This leads to issues like #770 Notably since nothing ever set the width value for queries, the old logic just always penalised non-regular widths, even if those were explicitly requested by name. In pathological cases this may have lead to mis-selections too. Addressing this and other issues in the current fontconfig provider properly requires at least switching it to lazy loading and possibly even a larger fontselect overhaul as proposed in #771. Considering a comprehensive solution will take a while, this patch provides an interim workaround alleviating at least the recent, particularly prominent regression giving us time to work on a proper solution. Fontconfig’s default pattern prefers normal widths, weight, etc matching exactly what we want here anyway. Notably this also adds a language parameter. Given its explicit removal for fallbacks it is unclear whether we really want this, but compared to an unspecified, potentially random order before this shouldn't hurt. Closes: #770
Fixes detection for nasm when using slibtoolize instead of GNU libtoolize. Fix from chimera-linux: chimera-linux/cports@fa52459 Signed-off-by: orbea <[email protected]>
This sets us back to muon 0.2.0 but avoids failures due to indev muon builds and tests.
Items retrieved from cache are always kept until at least the end of the frame, so there's no need to explicitly ref them when they're only used intra-frame. Instead, explicitly ref items when we'll be keeping them around for longer (e.g. as part of another cache item's key). Note that ass_shaper already depended on cache items never being released mid-frame prior to this change. This will save massively on atomic contention later.
No types or functions from it are actually used only some transitive header includes.
checkasm tests internal libass functions, but linked to the public libass library directly. Ths worked fine if a static lib is available, but if only a shared lib was built, symbol export control hides required functions leading to link-time failures. To workaround this create an internal static-only convenience library encompassing all libass sources. The real library is now just a thin linking wrapper around this.
In some cases, where there is a lot of simple text on the screen, the ass_render_event and quantize_transform were taking an unexpected amount of CPU time, causing frame drops. It turns out that lrint is the root cause of this, as it is not inlined. Allow it to be lowered to the cvtsd2si instruction. This change also helps with other similar cases and allows simple math functions to be inlined. Overall, rendering performance is 2.2 times faster than before, based on my test case.
Changed parameters always effectively acted as const albeit this wasn’t reflected in their declaration yet. `const char*` is always compatible to `char *` allowing us to change the following in a backwards-compatible way: - filenames - codepages (only passed along to iconv which takes const char*) - most input data (ecept when passed to iconv as `char** restrict`) In C++ `const char *const *` is compatible with both `const char **` and `char **`, but in C it’s only compatible with the former. Therefore we cannot change style overrrides for C users, but we can at least document the effective constness and make it explicit for C++ users.
These are simple wrappers around the libc malloc/free routines. Exposing them allows for safe heap usage across shared library boundaries in cases where there may be multiple instances of the libc functions present in the same process (e.g. libc statically linked into a shared lib). This mostly affects Windows.
Most of our allocation and destruction of harfbuzz objects has been streamlined since #566 was filed, so checking for singleton returns was all that was left.
This lets us check for warning flags at configure-time, avoiding introducing errors if a compiler doesn't support a particular flag.
This release fixes a 0.17.2 regression in the fontconfig font provider as well as some build issues. Furthermore it brings API enhancements and a performance improvement for a specific case. The newly added ass_malloc and ass_free API should always be used when directly interacting with libass-owned or provided data to be safe on setups with multiple allocators as it’s not too uncommon on Microsoft Windows. However libass continues to always use the standard allocators provided at build time; no currently working setups break.
When the used config is completely devoid of fonts FcFontSort will attempt to allocate an empty set and return it while still setting the result to invalid. Fortunately this seems unlikely to affect any real-world setups, but we should handle it correctly nevertheless. Identified-by: kasper93
Sum of all blur coefficients (including implicit center) is 0x8000, but each individual off-center coefficient is represented as int16_t, so it cannot be larger than 0x7FFF. For real blurs, center coefficient dominates all others, so param[i] are always less than 0x8000.
Removing unparseable, ignored garbage and bringing the content into standard formatting can make it much easier to tell what’s going on in a fuzzing sample and often shrinks the sample a fair bit as well.
This relies on each time component getting parsed as a 32-bit complement-of-two integer.
Commit cd35a4d added the -fno-math-errno flag which allows lrint() to be inlined on GCC and Clang. Unfortunately, Visual C++ can't inline lrint() without -fp:fast. That flag has some nasty implications, so I think it's better to just write our own lrint. This change helps a bit with the video sample from #736. It halves the number of dropped frames in MPC-HC on my machine (from ~180 to ~80). Resolves: #806
Partly addresses #529
Also print the platform name that we don't support, so it's clear what meson is detecting the platform as.
The version check was already implicitly rejecting it, but if in the future yasm releases a 2.10 version, people who have yasm but not nasm might start seeing build failures.
The preceeding commit cached the meson.get_compiler('nasm') lookup
for later reuse. However, the initial lookup occured even when nasm
was not found.
This is no issue for e.g. Linux native builds and no issue for
crossbuilds which do _not_ specify nasm in their crossfile and unse
meson >= 1.5.0. However, crossbuilds not specifying nasm in their
crossfile always fail with meson < 1.5.0 and native builds on Windows
fail as well if nasm wasn’t found; see e.g.:
https://github.com/mpv-player/mpv/actions/runs/10418042994/job/28853424386
Ideally meson would be more consistent in its handling and caching like
this would just work, but given the inconsistentcy across platforms in
practice and meson 1.5.0 only being around a month old let’s just rerun
the lookup where needed to avoid trouble during build.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )