beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 07:30:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/vcpkg.json

125 lines
2 KiB
JSON
Raw Normal View History

Meta+LibWebView: Install and link sqlite3 with vcpkg We will use sqlite3 as a replacement for LibSQL. Using a tried-and-true database will allow us to avoid maintaining our an incomplete, non-ACID, and less performant implementation. It also means we do not have to launch and manage the singleton SQLServer process.
2024-06-04 20:28:35 +00:00
{
Meta: Update vcpkg to the October 2024 release
2024-10-28 13:20:09 +00:00
"builtin-baseline": "10b7a178346f3f0abef60cecd5130e295afd8da4",
Meta+LibWebView: Install and link sqlite3 with vcpkg We will use sqlite3 as a replacement for LibSQL. Using a tried-and-true database will allow us to avoid maintaining our an incomplete, non-ACID, and less performant implementation. It also means we do not have to launch and manage the singleton SQLServer process.
2024-06-04 20:28:35 +00:00
"dependencies": [
RequestServer: Use libcurl for HTTP and HTTPS downloads This replaces the use of our home-grown implementations inherited from SerenityOS.
2024-09-05 11:20:09 +00:00
{
"name": "curl",
"features": [
Meta: Update curl to version 8.10.1 Contains a fix for CVE-2024-8096.
2024-09-19 18:21:49 +00:00
"brotli",
"http2"
RequestServer: Use libcurl for HTTP and HTTPS downloads This replaces the use of our home-grown implementations inherited from SerenityOS.
2024-09-05 11:20:09 +00:00
]
},
LibCore: Port DirIterator to Windows using vcpkg dirent.h
2024-10-24 17:56:43 +00:00
{
"name": "dirent",
"platform": "windows"
},
Ladybird: Use fontconfig to choose generic fonts on non-Apple systems If we get a suggestion from fontconfig, we try those fonts first, before falling back on the hard coded list of known suitable fonts for each generic family.
2024-06-07 17:50:00 +00:00
{
"name": "fontconfig",
Meta: Add windows options to vcpkg
2024-10-10 23:33:59 +00:00
"platform": "linux | freebsd | openbsd | osx | windows"
LibLocale: Install ICU package and link into LibLocale Rather than removing LibLocale entirely, we will use it as a wrapper around ICU (which has some C-like interfaces, and uses UTF-16 for its string types). Using ICU will provide better web compatibility overall, and will let us implement features we were previously unable to (e.g. Intl.Collator requires data that is not in the JSON export of the CLDR).
2024-06-08 15:10:10 +00:00
},
LibGfx+LibWeb: Use harfbuzz for text shaping This replaces glyph positioning system with harfbuzz's shaping algorithm. Adding support for bidirectional encoded text.
2024-08-13 16:05:43 +00:00
"harfbuzz",
LibLocale: Install ICU package and link into LibLocale Rather than removing LibLocale entirely, we will use it as a wrapper around ICU (which has some C-like interfaces, and uses UTF-16 for its string types). Using ICU will provide better web compatibility overall, and will let us implement features we were previously unable to (e.g. Intl.Collator requires data that is not in the JSON export of the CLDR).
2024-06-08 15:10:10 +00:00
"icu",
LibGfx: Remove home-grown JPEG codec in favor of libjpeg-turbo
2024-06-16 14:08:31 +00:00
"libjpeg-turbo",
LibGfx: Use libjxl to decode JPEG XL images It currently doesn't support animated image. Note that Gfx::Bitmap has no support for get_pixel when the format is RGBA8888. This is why it has been removed from the tests.
2024-07-21 21:23:28 +00:00
"libjxl",
LibGfx: Remove home-grown PNG codec in favor of libpng+apng
2024-06-18 19:06:15 +00:00
{
"name": "libpng",
LibCore+LibWeb: Use Metal backend for Skia painter on macOS If Metal context and IOSurface are available, Skia painter will use Ganesh GPU backend on macOS, which is noticeably faster than the default CPU backend. Painting pipeline: 1. (WebContent) Allocate IOSurface for backing store 2. (WebContent) Allocate MTLTexture that wraps IOSurface 3. (WebContent) Paint into MTLTexture using Skia 4. (Browser) Wrap IOSurface into Gfx::Painter and use QPainter/CoreGraphics to blit backing store into viewport. Things we should improve in the future: 1. Upload textures for images in advance instead of doing that before every repaint. 2. Teach AppKit client to read directly from IOSurface instead of copying.
2024-06-26 15:56:55 +00:00
"features": [
"apng"
]
},
LibGfx: Decode AVIF images Use libavif to decode AVIF images in LibGfx.
2024-07-06 07:33:38 +00:00
{
"name": "libavif",
"features": [
"dav1d"
]
},
LibGfx: Decode WebP images with libwebp
2024-07-12 08:08:39 +00:00
{
"name": "libwebp",
"features": [
"anim",
"libwebpmux",
"simd"
]
},
AK+LibWeb: Replace our home-grown base64 encoder/decoders with simdutf We currently have 2 base64 coders: one in AK, another in LibWeb for a "forgiving" implementation. ECMA-262 has an upcoming proposal which will require a third implementation. Instead, let's use the base64 implementation that is used by Node.js and recommended by the upcoming proposal. It handles forgiving decoding as well. Our users of AK's implementation should be fine with the forgiving implementation. The AK impl originally had naive forgiving behavior, but that was removed solely for performance reasons. Using http://mattmahoney.net/dc/enwik8.zip (100MB unzipped) as a test, performance of our old home-grown implementations vs. the simdutf implementation (on Linux x64): Encode Decode AK base64 0.226s 0.169s LibWeb base64 N/A 1.244s simdutf 0.161s 0.047s
2024-07-15 19:25:08 +00:00
"simdutf",
LibCore+LibWeb: Use Metal backend for Skia painter on macOS If Metal context and IOSurface are available, Skia painter will use Ganesh GPU backend on macOS, which is noticeably faster than the default CPU backend. Painting pipeline: 1. (WebContent) Allocate IOSurface for backing store 2. (WebContent) Allocate MTLTexture that wraps IOSurface 3. (WebContent) Paint into MTLTexture using Skia 4. (Browser) Wrap IOSurface into Gfx::Painter and use QPainter/CoreGraphics to blit backing store into viewport. Things we should improve in the future: 1. Upload textures for images in advance instead of doing that before every repaint. 2. Teach AppKit client to read directly from IOSurface instead of copying.
2024-06-26 15:56:55 +00:00
{
"name": "skia",
"platform": "osx",
"features": [
Ladybird+LibWeb+LibGfx: Add option to force use of fontconfig This allows us to get identical metrics on macOS and Linux. Without this, Skia will use CoreText on macOS and give us slightly different text metrics. That causes layout tests to be slightly different on different platforms, which is a huge headache. So let's not do that. You can now launch Ladybird and headless-browser with --force-fontconfig to load fonts through fontconfig. Tests run in this mode by default.
2024-08-19 18:35:49 +00:00
"metal",
"fontconfig"
LibCore+LibWeb: Use Metal backend for Skia painter on macOS If Metal context and IOSurface are available, Skia painter will use Ganesh GPU backend on macOS, which is noticeably faster than the default CPU backend. Painting pipeline: 1. (WebContent) Allocate IOSurface for backing store 2. (WebContent) Allocate MTLTexture that wraps IOSurface 3. (WebContent) Paint into MTLTexture using Skia 4. (Browser) Wrap IOSurface into Gfx::Painter and use QPainter/CoreGraphics to blit backing store into viewport. Things we should improve in the future: 1. Upload textures for images in advance instead of doing that before every repaint. 2. Teach AppKit client to read directly from IOSurface instead of copying.
2024-06-26 15:56:55 +00:00
]
},
{
"name": "skia",
Meta: Add windows options to vcpkg
2024-10-10 23:33:59 +00:00
"platform": "linux | freebsd | openbsd | windows",
LibWeb+LibCore: Use Vulkan backend for Skia on Linux Skia now uses GPU-accelerated painting on Linux if Vulkan is available. Most of the performance gain is currently negated by reading the GPU backend back into RAM to pass it to the Browser process. In the future, this could be improved by sharing GPU-allocated memory across the Browser and WebContent processes.
2024-07-03 17:23:27 +00:00
"features": [
"vulkan"
]
LibGfx: Remove home-grown PNG codec in favor of libpng+apng
2024-06-18 19:06:15 +00:00
},
Android: Integrate vcpkg with Gradle build This ensures that vcpkg downloads and builds all dependencies for Android. We add it as a CMAKE_TOOLCHAIN_FILE that then chainloads the Android NDK's toolchain file, as per the vcpkg documentation.
2024-07-03 19:17:16 +00:00
{
"name": "skia",
"platform": "android"
},
LibLocale: Install ICU package and link into LibLocale Rather than removing LibLocale entirely, we will use it as a wrapper around ICU (which has some C-like interfaces, and uses UTF-16 for its string types). Using ICU will provide better web compatibility overall, and will let us implement features we were previously unable to (e.g. Intl.Collator requires data that is not in the JSON export of the CLDR).
2024-06-08 15:10:10 +00:00
"sqlite3",
Meta: Add vulkan and vulkan-headers to vcpkg dependencies Also require a specific ICU version to not run into unexpected problems.
2024-07-05 22:12:52 +00:00
{
"name": "vulkan",
"platform": "!android"
},
{
"name": "vulkan-headers",
"platform": "!android"
AK+LibWeb: Replace our home-grown base64 encoder/decoders with simdutf We currently have 2 base64 coders: one in AK, another in LibWeb for a "forgiving" implementation. ECMA-262 has an upcoming proposal which will require a third implementation. Instead, let's use the base64 implementation that is used by Node.js and recommended by the upcoming proposal. It handles forgiving decoding as well. Our users of AK's implementation should be fine with the forgiving implementation. The AK impl originally had naive forgiving behavior, but that was removed solely for performance reasons. Using http://mattmahoney.net/dc/enwik8.zip (100MB unzipped) as a test, performance of our old home-grown implementations vs. the simdutf implementation (on Linux x64): Encode Decode AK base64 0.226s 0.169s LibWeb base64 N/A 1.244s simdutf 0.161s 0.047s
2024-07-15 19:25:08 +00:00
},
"woff2"
Meta+LibWebView: Install and link sqlite3 with vcpkg We will use sqlite3 as a replacement for LibSQL. Using a tried-and-true database will allow us to avoid maintaining our an incomplete, non-ACID, and less performant implementation. It also means we do not have to launch and manage the singleton SQLServer process.
2024-06-04 20:28:35 +00:00
],
"overrides": [
Meta: Update curl to version 8.10.1 Contains a fix for CVE-2024-8096.
2024-09-19 18:21:49 +00:00
{
"name": "curl",
"version": "8.10.1#0"
},
LibLocale: Install ICU package and link into LibLocale Rather than removing LibLocale entirely, we will use it as a wrapper around ICU (which has some C-like interfaces, and uses UTF-16 for its string types). Using ICU will provide better web compatibility overall, and will let us implement features we were previously unable to (e.g. Intl.Collator requires data that is not in the JSON export of the CLDR).
2024-06-08 15:10:10 +00:00
{
"name": "fontconfig",
"version": "2.14.2#1"
},
{
"name": "icu",
Meta: Update ICU to version 74.2#2 There is no functional change here, but they added an error message to the install output to indicate what host tools need to be installed. This has tripped some people up, so it seems worth updating to.
2024-06-22 19:10:03 +00:00
"version": "74.2#2"
LibLocale: Install ICU package and link into LibLocale Rather than removing LibLocale entirely, we will use it as a wrapper around ICU (which has some C-like interfaces, and uses UTF-16 for its string types). Using ICU will provide better web compatibility overall, and will let us implement features we were previously unable to (e.g. Intl.Collator requires data that is not in the JSON export of the CLDR).
2024-06-08 15:10:10 +00:00
},
LibGfx: Remove home-grown JPEG codec in favor of libjpeg-turbo
2024-06-16 14:08:31 +00:00
{
"name": "libjpeg-turbo",
"version": "3.0.2"
},
LibGfx: Use libjxl to decode JPEG XL images It currently doesn't support animated image. Note that Gfx::Bitmap has no support for get_pixel when the format is RGBA8888. This is why it has been removed from the tests.
2024-07-21 21:23:28 +00:00
{
"name": "libjxl",
Meta: Update libjxl to version 0.11.0
2024-09-19 23:55:19 +00:00
"version": "0.11.0"
LibGfx: Use libjxl to decode JPEG XL images It currently doesn't support animated image. Note that Gfx::Bitmap has no support for get_pixel when the format is RGBA8888. This is why it has been removed from the tests.
2024-07-21 21:23:28 +00:00
},
LibGfx: Remove home-grown PNG codec in favor of libpng+apng
2024-06-18 19:06:15 +00:00
{
"name": "libpng",
Meta: Update libpng to version 1.6.43#3 This is a fix to the vcpkg package itself to fix some exported symbols.
2024-09-19 20:19:42 +00:00
"version": "1.6.43#3"
LibGfx: Remove home-grown PNG codec in favor of libpng+apng
2024-06-18 19:06:15 +00:00
},
LibGfx: Decode AVIF images Use libavif to decode AVIF images in LibGfx.
2024-07-06 07:33:38 +00:00
{
"name": "libavif",
"version": "1.0.4#1"
},
LibGfx: Decode WebP images with libwebp
2024-07-12 08:08:39 +00:00
{
"name": "libwebp",
"version": "1.4.0#1"
},
AK+LibWeb: Replace our home-grown base64 encoder/decoders with simdutf We currently have 2 base64 coders: one in AK, another in LibWeb for a "forgiving" implementation. ECMA-262 has an upcoming proposal which will require a third implementation. Instead, let's use the base64 implementation that is used by Node.js and recommended by the upcoming proposal. It handles forgiving decoding as well. Our users of AK's implementation should be fine with the forgiving implementation. The AK impl originally had naive forgiving behavior, but that was removed solely for performance reasons. Using http://mattmahoney.net/dc/enwik8.zip (100MB unzipped) as a test, performance of our old home-grown implementations vs. the simdutf implementation (on Linux x64): Encode Decode AK base64 0.226s 0.169s LibWeb base64 N/A 1.244s simdutf 0.161s 0.047s
2024-07-15 19:25:08 +00:00
{
"name": "simdutf",
AK+Meta: Update simdutf to version 5.5.0 Contains many fixes found upstream by fuzzers. Also includes fixes for CPU-specific inconsistencies with null inputs.
2024-09-19 18:25:38 +00:00
"version": "5.5.0#0"
AK+LibWeb: Replace our home-grown base64 encoder/decoders with simdutf We currently have 2 base64 coders: one in AK, another in LibWeb for a "forgiving" implementation. ECMA-262 has an upcoming proposal which will require a third implementation. Instead, let's use the base64 implementation that is used by Node.js and recommended by the upcoming proposal. It handles forgiving decoding as well. Our users of AK's implementation should be fine with the forgiving implementation. The AK impl originally had naive forgiving behavior, but that was removed solely for performance reasons. Using http://mattmahoney.net/dc/enwik8.zip (100MB unzipped) as a test, performance of our old home-grown implementations vs. the simdutf implementation (on Linux x64): Encode Decode AK base64 0.226s 0.169s LibWeb base64 N/A 1.244s simdutf 0.161s 0.047s
2024-07-15 19:25:08 +00:00
},
LibWeb: Add Skia painting command executor This change introduces Skia painter available under a flag. It's not yet match capabilities of Gfx::Painter and is not ready to replace it. Motivation: - The current CPU painter is a performance bottleneck on most websites. Our own GPU painter implementation is very immature and has received relatively little attention. - There is ongoing effort on building painter that supports affine transforms (AffineCommandExecutorCPU) but it is far from being on par with the default CPU painter. Skia will allow us to immediately get full transformation support for all painting commands. GPU painting: I experimented with Ganesh GPU-backend, however profiling revealed that without sharing viewport texture between WebContent and Browser processes, it won't bring much performance improvement compared to CPU-backend. Therefore, I decided to keep this PR focused on implementing most of painting commands and switch to GPU-backend in future changes. Text rendring: Skia painter uses glyph bitmaps produced by LibGfx. Using Skia for text rendering will require large refactoring of the font rendering subsystem. Currently, it's impossible to construct SkFont right before rendering because Gfx::VectorFont can't be serialized back into sequence of bytes. There is a problem with ugly include paths like: `#include <core/SkBitmap.h>`. I would prefer to have skia prefix in the path. There was an attempt to fix that but PR was rejected https://github.com/microsoft/vcpkg/pull/32660 Regressions compared to Gfx::Painter: - DrawText is not implemented - PaintTextShadow is not implemented - PaintRadialGradient and PaintLinearGradient do not support "transition hints" and repeat length - PaintConicGradient is not implemented - DrawTriangleWave is not implemented - DrawLine does not account for line style property - DrawScaledBitmap and DrawScaledImmutableBitmap do not account for scaling mode property
2024-06-10 11:22:04 +00:00
{
"name": "skia",
Meta+LibWeb: Update Skia to version 129
2024-09-19 15:28:18 +00:00
"version": "129#0"
LibWeb: Add Skia painting command executor This change introduces Skia painter available under a flag. It's not yet match capabilities of Gfx::Painter and is not ready to replace it. Motivation: - The current CPU painter is a performance bottleneck on most websites. Our own GPU painter implementation is very immature and has received relatively little attention. - There is ongoing effort on building painter that supports affine transforms (AffineCommandExecutorCPU) but it is far from being on par with the default CPU painter. Skia will allow us to immediately get full transformation support for all painting commands. GPU painting: I experimented with Ganesh GPU-backend, however profiling revealed that without sharing viewport texture between WebContent and Browser processes, it won't bring much performance improvement compared to CPU-backend. Therefore, I decided to keep this PR focused on implementing most of painting commands and switch to GPU-backend in future changes. Text rendring: Skia painter uses glyph bitmaps produced by LibGfx. Using Skia for text rendering will require large refactoring of the font rendering subsystem. Currently, it's impossible to construct SkFont right before rendering because Gfx::VectorFont can't be serialized back into sequence of bytes. There is a problem with ugly include paths like: `#include <core/SkBitmap.h>`. I would prefer to have skia prefix in the path. There was an attempt to fix that but PR was rejected https://github.com/microsoft/vcpkg/pull/32660 Regressions compared to Gfx::Painter: - DrawText is not implemented - PaintTextShadow is not implemented - PaintRadialGradient and PaintLinearGradient do not support "transition hints" and repeat length - PaintConicGradient is not implemented - DrawTriangleWave is not implemented - DrawLine does not account for line style property - DrawScaledBitmap and DrawScaledImmutableBitmap do not account for scaling mode property
2024-06-10 11:22:04 +00:00
},
Meta+LibWebView: Install and link sqlite3 with vcpkg We will use sqlite3 as a replacement for LibSQL. Using a tried-and-true database will allow us to avoid maintaining our an incomplete, non-ACID, and less performant implementation. It also means we do not have to launch and manage the singleton SQLServer process.
2024-06-04 20:28:35 +00:00
{
"name": "sqlite3",
Meta: Update sqlite3 to version 3.46.1
2024-09-19 18:48:08 +00:00
"version": "3.46.1"
LibGfx: Use the woff2 library to decode WOFF2 font files This saves us the trouble of maintaining our own implementation, and instantly brings us to full WOFF2 feature parity with others. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2024-06-06 09:10:01 +00:00
},
{
"name": "woff2",
"version": "1.0.2#4"
Meta+LibWebView: Install and link sqlite3 with vcpkg We will use sqlite3 as a replacement for LibSQL. Using a tried-and-true database will allow us to avoid maintaining our an incomplete, non-ACID, and less performant implementation. It also means we do not have to launch and manage the singleton SQLServer process.
2024-06-04 20:28:35 +00:00
}
]
}
Reference in a new issue Copy permalink