CMYK data describes which inks a printer should use to print a color.
If a screen should display a color that's supposed to look similar
to what the printer produces, it results in a color very different
to what Color::from_cmyk() produces. (It's also printer-dependent.)
There are many ICC profiles describing printing processes. It doesn't
matter too much which one we use -- most of them look somewhat
similar, and they all look dramatically better than Color::from_cmyk().
This patch adds a function to download a zip file that Adobe offers
on their web site. They even have a page for redistribution:
https://www.adobe.com/support/downloads/iccprofiles/icc_eula_win_dist.html
(That one leads to a broken download though, so this downloads the
end-user version.)
In case we have to move off this download at some point, there are also
a whole bunch of profiles at https://www.color.org/registry/index.xalter
that "may be used, embedded, exchanged, and shared without restriction".
The adobe zip contains a whole bunch of other useful and fun profiles,
so I went with it.
For now, this only unzips the USWebCoatedSWOP.icc file though, and
installs it in ${CMAKE_BINARY_DIR}/Root/res/icc/Adobe/CMYK/. In
Serenity builds, this will make it to /res/icc/Adobe/CMYK in the
disk image. And in lagom build, after #23016 this is the
lagom res staging directory that tools can install via
Core::ResourceImplementation. `pdf` and `MacPDF` already do that,
`TestPDF` now does it too.
The final piece is that LibPDF then loads the profile from there
and uses it for DeviceCMYK color conversions.
(Doing file access from the bowels of a library is a bit weird,
especially in a system that has sandboxing built in. But LibGfx does
that in FontDatabase too already, and LibPDF uses that, so it's not a
new problem.)
This patch removes the explicit compile flag that only works for g++
(`-fdiagnostics-color=always`; clang++ needs `-fcolor-diagnostics`) and
uses CMake's built in variable that can control color output.
Now both compilers should output colored diagnostics.
This lets us fail early at configure time if a suitable Python 3
interpreter is not present, instead of delaying the error until Ninja
attempts to run `embed_as_string_view.py` to generate a header in the
middle of the build.
Refs #21791
Also explicitly specify `-mstrict-align` (The current default `-mcpu`
on gcc doesn't support unaligned accesses, so aligned memory accesses
are already implicitly required).
The `-Wcast-align` warning seems to oversensitive as it flags code like
this: https://godbolt.org/z/c8481o8aa
This used to be added for aarch64 in a473cfd71b, but was later removed
in 11896868d6.
These can be quite verbose on the command line if the packages aren't
found. As they do not break the build, let's not spam warnings.
The OpenGL package is also now skipped on macOS, where there's no point
in looking for the package anyways.
ASAN was crying way too much when running the LibJS JIT since the old
OFFSET_OF implementation was too wild for its liking.
By turning off the invalid-offsetof warnings, we can use the offsetof
builtin instead. However, I'm leaving this as a wrapper macro, since
we may still want to do something different for other compilers.
FP contraction is a standard-conforming behavior which allows the
compiler to calculate intermediate results of expressions containing
floating point numbers with a greater precision than the expression type
allows. And in theory, it enables additional optimizations, such as
replacing `a * b + c` with fma(a, b, c).
Unfortunately, it is extremely hard to predict when the contraction will
happen. For example, Clang 17 on x86_64 with the default options will
use FMA only for constant-folded non-constexpr expressions. So, in
practice, FP contraction leads to hard-to-find bugs and inconsistencies
between executables compiled with different toolchains or for different
OSes. And we had two instances of this happening last week.
Since we did not ever used -mfma on x86_64, this patch can only possibly
regress performance on Apple ARM devices, where FMA is enabled by
default. However, this regression will likely be negligible since the
difference would be one additional add instruction, which would be then
likely executed in parallel with something else.
With these changes it is now possible to create OpenGL context on macOS
and run GPU-painter. For now only QT client has a CLI param that turns
it on though.
This is a bit spammy now that we are performing some overload resolution
at build time. The fallback to an interface has generally worked fine on
the types it warns about (BufferSource, Module, etc.) so let's not warn
about it for every build.
https://cldr.unicode.org/index/downloads/cldr-44
Notable changes that affect us include:
* The Islamic Calendar is now localized as the Hijri Calender (in en-US)
but has not been updated for all locales. So this patch updates tests
where possible and removes a few test cases that currently cannot be
localized.
* The und locale has received more likely subtag data (the und locale is
basically a pseudo-locale meaning "undetermined").
* The exponential symbol in the Arabic number system was changed from
U+0627 to U+0623.
This warning warns about variable-length arrays being a non-standard
extension to the C++ language. We still have a few instances of VLAs, so
let's disable the warning for now.
This does not interfere with `-Wvla`, which we use to completely forbid
this (potentially dangerous) feature in the Kernel and LibCrypto.
A bit old but a relatively uncomplicated device capable of outputting
1920x1080 video with 32-bit color. Tested with a Voodoo 3 3000 16MB
PCI card. Resolution switching from DisplaySettings also works.
If the requested mode contains timing information, it is used directly.
Otherwise, display timing values are selected from the EDID. First the
detailed timings are checked, and then standard and established
timings for which there is a matching DMT mode. The driver does not
(yet) read the actual EDID, so the generic EDID in DisplayConnector now
includes a set of common display modes to make this work.
The driver should also be compatible with the Voodoo Banshee, 4 and 5
but I don't have these cards to test this with. The PCI IDs of these
cards are included as a commented line in case someone wants to give it
a try.
When this feature was finally merged, the serenity_option in
lagom_options.cmake had the unintended side effect of always setting the
cache variable to "" in the initial cache. In order to actually set the
linker to use to be lld or mold, we need to set with the FORCE flag in
the use_linker.cmake file.
Found by checking with the CMake variable_watch() function.
This will stop the build from spamming the "Using LLD to link Lagom"
message all over the place :^)
For now, part of this is commented-out. Our current implementations of
`<mask>` and `<symbol>` rely on creating layout nodes, so they can't be
`display: none`.
This flag makes the linker bind default-visibility functions locally, so
that calls to them do not have to go through the PLT. This makes it
impossible to override them by preloading a DSO. This was already the
case partially due to `-fno-semantic-interposition`, however that flag
is only able to optimize call sites that are in the same Translation
Unit as the function definitions.
This removes 80% of the PLT relocations in `libjs.so.serenity`.
Obsoletes #20877
This makes CMake pass `-fpie` instead of `-fpic` to the compiler when
building the Kernel and userland *executables*. This allows the compiler
to make certain optimizations based on the fact that the code will be
used in an executable, such as not having to emit `.localalias` symbols.
This leads to a 450 KiB decrease in the size of the Kernel binary.
https://unicode.org/versions/Unicode15.1.0/
This update includes a new set of code point properties, Indic Conjunct
Break. These may have the values Consonant, Linker, or Extend. These are
used in text segmentation to prevent breaking on some extended grapheme
cluster sequences.
This ports over the `LADYBIRD_USE_LLD` option from the standalone
Ladybird build and generalizes it to work for mold as well: the
`LAGOM_USE_LINKER` variable can be set to the desired name of the
linker. If it's empty, we default to trying LLD and Mold on ELF
platforms (in this order).
We currently only use frame pointer-based backtrace generation.
This option is necessary for RISC-V as otherwise the compiler doesn't
save `fp` most of the time.
I made this flag not riscv64 exclusive, as we should do everything
to make that kind of backtrace generation work.
(https://discord.com/channels/830522505605283862/1139481927594803260/1148020960499351643)
This template app from Android Studio should hopefully be more fun to
work on than the Qt wrapped application we were using before. :^)
It currently builds the native code using gradle rules, and has a stub
WebViewImplementationNative class that will wrap a c++ class of the same
name that inhertis from WebView::ViewImplementation. Spawning helper
processes and creating proper views in Kotlin is next on the list.
