Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Painting/BackingStoreManager.cpp

176 lines
6.7 KiB
C++
Raw Normal View History

LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
/*
LibWeb+LibGfx: Replace BackingStore with PaintingSurface Now, when Skia backend context is available by the time backing stores are allocated, there is no need to have a separate BackingStore class. This allows us to get rid of BackingStore -> PaintingSurface cache.
2025-06-27 04:39:16 +02:00
* Copyright (c) 2024-2025, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibCore/Timer.h>
LibWeb: Rearrange code such that a lot less files include `Command.h` With this change number of recompiled files after modification of `Command.h` goes down from >1000 to <100.
2025-07-10 19:24:30 +02:00
#include <LibGfx/PaintingSurface.h>
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
#include <LibWeb/HTML/TraversableNavigable.h>
LibWeb+WebContent+WebWorker: Move backing store allocation in Navigable Making navigables responsible for backing store allocation will allow us to have separate backing stores for iframes and run paint updates for them independently, which is a step toward isolating them into separate processes. Another nice side effect is that now Skia backend context is ready by the time backing stores are allocated, so we will be able to get rid of BackingStore class in the upcoming changes and allocate PaintingSurface directly.
2025-06-26 22:33:58 +02:00
#include <LibWeb/Painting/BackingStoreManager.h>
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
#include <WebContent/PageClient.h>
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
#ifdef AK_OS_MACOS
# include <LibCore/IOSurface.h>
# include <LibCore/MachPort.h>
# include <LibCore/Platform/MachMessageTypes.h>
#endif
LibWeb+WebContent+WebWorker: Move backing store allocation in Navigable Making navigables responsible for backing store allocation will allow us to have separate backing stores for iframes and run paint updates for them independently, which is a step toward isolating them into separate processes. Another nice side effect is that now Skia backend context is ready by the time backing stores are allocated, so we will be able to get rid of BackingStore class in the upcoming changes and allocate PaintingSurface directly.
2025-06-26 22:33:58 +02:00
namespace Web::Painting {
GC_DEFINE_ALLOCATOR(BackingStoreManager);
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
#ifdef AK_OS_MACOS
static Optional<Core::MachPort> s_browser_mach_port;
void BackingStoreManager::set_browser_mach_port(Core::MachPort&& port)
{
s_browser_mach_port = move(port);
}
#endif
LibWeb+WebContent+WebWorker: Move backing store allocation in Navigable Making navigables responsible for backing store allocation will allow us to have separate backing stores for iframes and run paint updates for them independently, which is a step toward isolating them into separate processes. Another nice side effect is that now Skia backend context is ready by the time backing stores are allocated, so we will be able to get rid of BackingStore class in the upcoming changes and allocate PaintingSurface directly.
2025-06-26 22:33:58 +02:00
BackingStoreManager::BackingStoreManager(HTML::Navigable& navigable)
: m_navigable(navigable)
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
{
m_backing_store_shrink_timer = Core::Timer::create_single_shot(3000, [this] {
resize_backing_stores_if_needed(WindowResizingInProgress::No);
});
}
LibWeb+WebContent+WebWorker: Move backing store allocation in Navigable Making navigables responsible for backing store allocation will allow us to have separate backing stores for iframes and run paint updates for them independently, which is a step toward isolating them into separate processes. Another nice side effect is that now Skia backend context is ready by the time backing stores are allocated, so we will be able to get rid of BackingStore class in the upcoming changes and allocate PaintingSurface directly.
2025-06-26 22:33:58 +02:00
void BackingStoreManager::visit_edges(Cell::Visitor& visitor)
{
Base::visit_edges(visitor);
visitor.visit(m_navigable);
}
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
void BackingStoreManager::restart_resize_timer()
{
m_backing_store_shrink_timer->restart();
}
LibWeb: Rearrange code such that a lot less files include `Command.h` With this change number of recompiled files after modification of `Command.h` goes down from >1000 to <100.
2025-07-10 19:24:30 +02:00
BackingStoreManager::BackingStore BackingStoreManager::acquire_store_for_next_frame()
{
BackingStore backing_store;
backing_store.bitmap_id = m_back_bitmap_id;
backing_store.store = m_back_store;
swap_back_and_front();
return backing_store;
}
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
void BackingStoreManager::reallocate_backing_stores(Gfx::IntSize size)
{
LibWeb+LibGfx: Replace BackingStore with PaintingSurface Now, when Skia backend context is available by the time backing stores are allocated, there is no need to have a separate BackingStore class. This allows us to get rid of BackingStore -> PaintingSurface cache.
2025-06-27 04:39:16 +02:00
auto skia_backend_context = m_navigable->skia_backend_context();
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
#ifdef AK_OS_MACOS
LibWeb+LibGfx: Replace BackingStore with PaintingSurface Now, when Skia backend context is available by the time backing stores are allocated, there is no need to have a separate BackingStore class. This allows us to get rid of BackingStore -> PaintingSurface cache.
2025-06-27 04:39:16 +02:00
if (skia_backend_context && s_browser_mach_port.has_value()) {
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
auto back_iosurface = Core::IOSurfaceHandle::create(size.width(), size.height());
auto back_iosurface_port = back_iosurface.create_mach_port();
auto front_iosurface = Core::IOSurfaceHandle::create(size.width(), size.height());
auto front_iosurface_port = front_iosurface.create_mach_port();
m_front_bitmap_id = m_next_bitmap_id++;
m_back_bitmap_id = m_next_bitmap_id++;
LibWeb+WebContent+WebWorker: Move backing store allocation in Navigable Making navigables responsible for backing store allocation will allow us to have separate backing stores for iframes and run paint updates for them independently, which is a step toward isolating them into separate processes. Another nice side effect is that now Skia backend context is ready by the time backing stores are allocated, so we will be able to get rid of BackingStore class in the upcoming changes and allocate PaintingSurface directly.
2025-06-26 22:33:58 +02:00
auto& page_client = m_navigable->top_level_traversable()->page().client();
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
Core::Platform::BackingStoreMetadata metadata;
LibWeb+WebContent+WebWorker: Move backing store allocation in Navigable Making navigables responsible for backing store allocation will allow us to have separate backing stores for iframes and run paint updates for them independently, which is a step toward isolating them into separate processes. Another nice side effect is that now Skia backend context is ready by the time backing stores are allocated, so we will be able to get rid of BackingStore class in the upcoming changes and allocate PaintingSurface directly.
2025-06-26 22:33:58 +02:00
metadata.page_id = page_client.id();
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
metadata.front_backing_store_id = m_front_bitmap_id;
metadata.back_backing_store_id = m_back_bitmap_id;
Core::Platform::MessageWithBackingStores message;
message.header.msgh_remote_port = s_browser_mach_port->port();
message.header.msgh_local_port = MACH_PORT_NULL;
message.header.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0) | MACH_MSGH_BITS_COMPLEX;
message.header.msgh_size = sizeof(message);
message.header.msgh_id = Core::Platform::BACKING_STORE_IOSURFACES_MESSAGE_ID;
message.body.msgh_descriptor_count = 2;
message.front_descriptor.name = front_iosurface_port.release();
message.front_descriptor.disposition = MACH_MSG_TYPE_MOVE_SEND;
message.front_descriptor.type = MACH_MSG_PORT_DESCRIPTOR;
message.back_descriptor.name = back_iosurface_port.release();
message.back_descriptor.disposition = MACH_MSG_TYPE_MOVE_SEND;
message.back_descriptor.type = MACH_MSG_PORT_DESCRIPTOR;
message.metadata = metadata;
mach_msg_timeout_t const timeout = 100; // milliseconds
auto const send_result = mach_msg(&message.header, MACH_SEND_MSG | MACH_SEND_TIMEOUT, message.header.msgh_size, 0, MACH_PORT_NULL, timeout, MACH_PORT_NULL);
if (send_result != KERN_SUCCESS) {
dbgln("Failed to send message to server: {}", mach_error_string(send_result));
VERIFY_NOT_REACHED();
}
LibWeb+LibGfx: Replace BackingStore with PaintingSurface Now, when Skia backend context is available by the time backing stores are allocated, there is no need to have a separate BackingStore class. This allows us to get rid of BackingStore -> PaintingSurface cache.
2025-06-27 04:39:16 +02:00
m_front_store = Gfx::PaintingSurface::create_from_iosurface(move(front_iosurface), *skia_backend_context);
m_back_store = Gfx::PaintingSurface::create_from_iosurface(move(back_iosurface), *skia_backend_context);
Everywhere: Pass backing store into Navigable::paint() ...instead of Gfx::Bitmap, which makes it possible to access and directly paint into IOSurface on macOS.
2024-06-25 16:43:39 +02:00
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
return;
}
#endif
m_front_bitmap_id = m_next_bitmap_id++;
m_back_bitmap_id = m_next_bitmap_id++;
LibGfx: Store alpha type information in `Gfx::Bitmap` We use instances of `Gfx::Bitmap` to move pixel data all the way from raw image bytes up to the Skia renderer. A vital piece of information for correct blending of bitmaps is the alpha type, i.e. are we dealing with premultiplied or unpremultiplied color values? Premultiplied means that the RGB colors have been multiplied with the associated alpha value, i.e. RGB(255, 255, 255) with an alpha of 2% is stored as RGBA(5, 5, 5, 2%). Unpremultiplied means that the original RGB colors are stored, regardless of the alpha value. I.e. RGB(255, 255, 255) with an alpha of 2% is stored as RGBA(255, 255, 255, 2%). It is important to know how the color data is stored in a `Gfx::Bitmap`, because correct blending depends on knowing the alpha type: premultiplied blending uses `S + (1 - A) * D`, while unpremultiplied blending uses `A * S + (1 - A) * D`. This adds the alpha type information to `Gfx::Bitmap` across the board. It isn't used anywhere yet.
2024-08-02 12:52:14 +02:00
auto front_bitmap = Gfx::Bitmap::create_shareable(Gfx::BitmapFormat::BGRA8888, Gfx::AlphaType::Premultiplied, size).release_value();
auto back_bitmap = Gfx::Bitmap::create_shareable(Gfx::BitmapFormat::BGRA8888, Gfx::AlphaType::Premultiplied, size).release_value();
Everywhere: Pass backing store into Navigable::paint() ...instead of Gfx::Bitmap, which makes it possible to access and directly paint into IOSurface on macOS.
2024-06-25 16:43:39 +02:00
LibWeb+LibGfx: Replace BackingStore with PaintingSurface Now, when Skia backend context is available by the time backing stores are allocated, there is no need to have a separate BackingStore class. This allows us to get rid of BackingStore -> PaintingSurface cache.
2025-06-27 04:39:16 +02:00
#ifdef USE_VULKAN
if (skia_backend_context) {
m_front_store = Gfx::PaintingSurface::create_with_size(skia_backend_context, size, Gfx::BitmapFormat::BGRA8888, Gfx::AlphaType::Premultiplied);
m_front_store->on_flush = [front_bitmap](auto& surface) {
surface.read_into_bitmap(*front_bitmap);
};
m_back_store = Gfx::PaintingSurface::create_with_size(skia_backend_context, size, Gfx::BitmapFormat::BGRA8888, Gfx::AlphaType::Premultiplied);
m_back_store->on_flush = [back_bitmap](auto& surface) {
surface.read_into_bitmap(*back_bitmap);
};
}
#endif
if (!m_front_store)
m_front_store = Gfx::PaintingSurface::wrap_bitmap(*front_bitmap);
if (!m_back_store)
m_back_store = Gfx::PaintingSurface::wrap_bitmap(*back_bitmap);
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
LibWeb+WebContent+WebWorker: Move backing store allocation in Navigable Making navigables responsible for backing store allocation will allow us to have separate backing stores for iframes and run paint updates for them independently, which is a step toward isolating them into separate processes. Another nice side effect is that now Skia backend context is ready by the time backing stores are allocated, so we will be able to get rid of BackingStore class in the upcoming changes and allocate PaintingSurface directly.
2025-06-26 22:33:58 +02:00
if (m_navigable->is_top_level_traversable()) {
auto& page_client = m_navigable->top_level_traversable()->page().client();
page_client.page_did_allocate_backing_stores(m_front_bitmap_id, front_bitmap->to_shareable_bitmap(), m_back_bitmap_id, back_bitmap->to_shareable_bitmap());
}
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
}
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
void BackingStoreManager::resize_backing_stores_if_needed(WindowResizingInProgress window_resize_in_progress)
{
LibWeb: Skip backing store allocation for traversables created for SVG Recently, we moved the backing store manager into Navigable, which means we now try to allocate a backing store for all navigables, including those corresponding to SVG image documents. This change disables that behavior for all navigables except top-level non-SVG traversables, because otherwise it causes issues when we stop repainting: the browser process was notified about an allocated backing stores that does not correspond to the page, and then all subsequent repaints are ignored until the window is resized.
2025-07-12 23:38:18 +02:00
if (!m_navigable->is_top_level_traversable() || m_navigable->is_svg_page())
return;
LibWeb+WebContent+WebWorker: Move backing store allocation in Navigable Making navigables responsible for backing store allocation will allow us to have separate backing stores for iframes and run paint updates for them independently, which is a step toward isolating them into separate processes. Another nice side effect is that now Skia backend context is ready by the time backing stores are allocated, so we will be able to get rid of BackingStore class in the upcoming changes and allocate PaintingSurface directly.
2025-06-26 22:33:58 +02:00
auto viewport_size = m_navigable->page().css_to_device_rect(m_navigable->viewport_rect()).size();
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
if (viewport_size.is_empty())
return;
Web::DevicePixelSize minimum_needed_size;
if (window_resize_in_progress == WindowResizingInProgress::Yes) {
// Pad the minimum needed size so that we don't have to keep reallocating backing stores while the window is being resized.
minimum_needed_size = { viewport_size.width() + 256, viewport_size.height() + 256 };
} else {
// If we're not in the middle of a resize, we can shrink the backing store size to match the viewport size.
minimum_needed_size = viewport_size;
Everywhere: Pass backing store into Navigable::paint() ...instead of Gfx::Bitmap, which makes it possible to access and directly paint into IOSurface on macOS.
2024-06-25 16:43:39 +02:00
m_front_store.clear();
m_back_store.clear();
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
}
Everywhere: Pass backing store into Navigable::paint() ...instead of Gfx::Bitmap, which makes it possible to access and directly paint into IOSurface on macOS.
2024-06-25 16:43:39 +02:00
if (!m_front_store || !m_back_store || !m_front_store->size().contains(minimum_needed_size.to_type<int>())) {
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
reallocate_backing_stores(minimum_needed_size.to_type<int>());
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
}
}
void BackingStoreManager::swap_back_and_front()
{
Everywhere: Pass backing store into Navigable::paint() ...instead of Gfx::Bitmap, which makes it possible to access and directly paint into IOSurface on macOS.
2024-06-25 16:43:39 +02:00
swap(m_front_store, m_back_store);
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
swap(m_front_bitmap_id, m_back_bitmap_id);
}
}
Reference in a new issue Copy permalink