dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Services/ImageDecoder/ConnectionFromClient.h

86 lines
3.1 KiB
C
Raw Permalink Normal View History

ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 16:35:22 -03:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 08:19:50 -03:00
* Copyright (c) 2020, Andreas Kling <andreas@ladybird.org>
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 16:35:22 -03:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 05:24:48 -03:00
* SPDX-License-Identifier: BSD-2-Clause
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 16:35:22 -03:00
*/
#pragma once
ImageDecoder: Decode images on ThreadPool Dispatch image decode work to ThreadPool workers instead of the old BackgroundAction helper. BackgroundAction funneled all jobs through one background thread, so image decodes were still serialized. The pool lets independent decode jobs run in parallel while completions are posted back to the origin event loop. Keep pending decode state as a small cancel flag. Make animated sessions ref-counted with a mutex so overlapping frame requests cannot race shared decoders once jobs run in parallel.
2026-06-04 19:47:10 -03:00
#include <AK/Atomic.h>
#include <AK/AtomicRefCounted.h>
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 16:35:22 -03:00
#include <AK/HashMap.h>
#include <ImageDecoder/Forward.h>
LibIPC: Share most of the code between {Client,Server}Connection This patch introduces IPC::Connection which becomes the new base class of ClientConnection and ServerConnection. Most of the functionality has been hoisted up to the base class since almost all of it is useful on both sides. This gives us the ability to send synchronous messages in both directions, which is needed for the WebContent server process. Unlike other servers, WebContent does not mind blocking on a response from its client.
2020-09-12 06:44:00 -03:00
#include <ImageDecoder/ImageDecoderClientEndpoint.h>
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 16:35:22 -03:00
#include <ImageDecoder/ImageDecoderServerEndpoint.h>
ImageDecoder: Add streaming animation decode sessions Add IPC messages and server-side implementation for streaming animated image decode. Instead of decoding all frames upfront, only decode an initial batch and keep the decoder alive for on-demand frame requests. New IPC messages: - request_animation_frames: request decode of a batch of frames - stop_animation_decode: clean up a decode session - did_decode_animation_frames: deliver decoded frames to client - did_fail_animation_decode: report decode errors The existing did_decode_image message gains a session_id parameter (0 for single-shot decode, non-zero for streaming sessions).
2026-02-13 11:03:35 -03:00
#include <LibCore/AnonymousBuffer.h>
ImageDecoder+LibGfx: Collate decoded bitmaps before sending over IPC There is an issue where gifs with many frames cannot be loaded, as each bitmap is sent over IPC using a separate file descriptor, and there is limit on the maximum number of descriptors per IPC message. Thus, trying to load gifs with more than 64 frames (the current limit) causes the image decoder process to die. This commit introduces the BitmapSequence class, which is a thin wrapper around the type Vector<Optional<NonnullRefPtr<Gfx::Bitmap>>> and provides an IPC encode/decode routine that collates all bitmap data into a single buffer so that only a single file descriptor is required per IPC transfer, even if multiple frames are being sent.
2024-09-18 18:37:44 -03:00
#include <LibGfx/BitmapSequence.h>
LibGfx+LibWeb: Do some color management on images with an ICC profile This patch introduces the `Gfx::ColorSpace` class, this is basically a serializable wrapper for skia's SkColorSpace. Creation of the instances of this class (and thus ICC profiles parsing) is performed in the ImageDecoder process. Then the object is serialized and sent through IPC, to finally be handed to skia for rendering. However, to make sure that we're not making all LibGfx's users dependent on Skia as well, we need to ensure the `Gfx::ColorSpace` object has no dependency on objects from Skia. To that end, the only member of the `ColorSpace` class is the opaque `ColorSpaceImpl` struct. Though, there is on issue with that design, the code in `DisplayListPlayer.cpp` needs access to the underlying `sk_sp<SkColorSpace>`. It is provided by a template function, that is only specialized for this type. Doing this work allows us to pass the following WPT tests: - https://wpt.live/css/css-color/tagged-images-001.html - https://wpt.live/css/css-color/tagged-images-003.html - https://wpt.live/css/css-color/tagged-images-004.html - https://wpt.live/css/css-color/untagged-images-001.html Other test cases can also be found here: - https://github.com/svgeesus/PNG-ICC-tests Note that SkColorSpace support quite a limited amount of color spaces, so color profiles like the ones in [1] or the v4 profiles in [2] are not supported yet. In fact, SkColorSpace only accepts skcms_ICCProfile with a linear conversion to XYZ D50. [1] https://www.color.org/browsertest.xalter [2] https://www.color.org/version4html.xalter
2024-12-02 20:55:43 -03:00
#include <LibGfx/ColorSpace.h>
ImageDecoder: Add streaming animation decode sessions Add IPC messages and server-side implementation for streaming animated image decode. Instead of decoding all frames upfront, only decode an initial batch and keep the decoder alive for on-demand frame requests. New IPC messages: - request_animation_frames: request decode of a batch of frames - stop_animation_decode: clean up a decode session - did_decode_animation_frames: deliver decoded frames to client - did_fail_animation_decode: report decode errors The existing did_decode_image message gains a session_id parameter (0 for single-shot decode, non-zero for streaming sessions).
2026-02-13 11:03:35 -03:00
#include <LibGfx/ImageFormats/ImageDecoder.h>
Userland: Rename IPC ClientConnection => ConnectionFromClient This was done with CLion's automatic rename feature and with: find . -name ClientConnection.h | rename 's/ClientConnection\.h/ConnectionFromClient.h/' find . -name ClientConnection.cpp | rename 's/ClientConnection\.cpp/ConnectionFromClient.cpp/'
2022-02-25 07:18:30 -03:00
#include <LibIPC/ConnectionFromClient.h>
ImageDecoder: Decode images on ThreadPool Dispatch image decode work to ThreadPool workers instead of the old BackgroundAction helper. BackgroundAction funneled all jobs through one background thread, so image decodes were still serialized. The pool lets independent decode jobs run in parallel while completions are posted back to the origin event loop. Keep pending decode state as a small cancel flag. Make animated sessions ref-counted with a mutex so overlapping frame requests cannot race shared decoders once jobs run in parallel.
2026-06-04 19:47:10 -03:00
#include <LibSync/Mutex.h>
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 16:35:22 -03:00
namespace ImageDecoder {
Userland: Rename IPC ClientConnection => ConnectionFromClient This was done with CLion's automatic rename feature and with: find . -name ClientConnection.h | rename 's/ClientConnection\.h/ConnectionFromClient.h/' find . -name ClientConnection.cpp | rename 's/ClientConnection\.cpp/ConnectionFromClient.cpp/'
2022-02-25 07:18:30 -03:00
class ConnectionFromClient final
: public IPC::ConnectionFromClient<ImageDecoderClientEndpoint, ImageDecoderServerEndpoint> {
C_OBJECT(ConnectionFromClient);
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 16:35:22 -03:00
public:
Services: Use default constructors/destructors https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-23 23:58:03 -03:00
~ConnectionFromClient() override = default;
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 16:35:22 -03:00
virtual void die() override;
ImageDecoder: Schedule decode jobs on the LibThreading background thread This allows the ImageDecoder service to handle new IPC requests while decoding in parallel.
2024-04-23 21:58:52 -03:00
struct DecodeResult {
bool is_animated = false;
u32 loop_count = 0;
ImageDecoder: Add streaming animation decode sessions Add IPC messages and server-side implementation for streaming animated image decode. Instead of decoding all frames upfront, only decode an initial batch and keep the decoder alive for on-demand frame requests. New IPC messages: - request_animation_frames: request decode of a batch of frames - stop_animation_decode: clean up a decode session - did_decode_animation_frames: deliver decoded frames to client - did_fail_animation_decode: report decode errors The existing did_decode_image message gains a session_id parameter (0 for single-shot decode, non-zero for streaming sessions).
2026-02-13 11:03:35 -03:00
u32 frame_count = 0;
ImageDecoder: Schedule decode jobs on the LibThreading background thread This allows the ImageDecoder service to handle new IPC requests while decoding in parallel.
2024-04-23 21:58:52 -03:00
Gfx::FloatPoint scale { 1, 1 };
ImageDecoder+LibGfx: Collate decoded bitmaps before sending over IPC There is an issue where gifs with many frames cannot be loaded, as each bitmap is sent over IPC using a separate file descriptor, and there is limit on the maximum number of descriptors per IPC message. Thus, trying to load gifs with more than 64 frames (the current limit) causes the image decoder process to die. This commit introduces the BitmapSequence class, which is a thin wrapper around the type Vector<Optional<NonnullRefPtr<Gfx::Bitmap>>> and provides an IPC encode/decode routine that collates all bitmap data into a single buffer so that only a single file descriptor is required per IPC transfer, even if multiple frames are being sent.
2024-09-18 18:37:44 -03:00
Gfx::BitmapSequence bitmaps;
ImageDecoder: Schedule decode jobs on the LibThreading background thread This allows the ImageDecoder service to handle new IPC requests while decoding in parallel.
2024-04-23 21:58:52 -03:00
Vector<u32> durations;
LibGfx+LibWeb: Do some color management on images with an ICC profile This patch introduces the `Gfx::ColorSpace` class, this is basically a serializable wrapper for skia's SkColorSpace. Creation of the instances of this class (and thus ICC profiles parsing) is performed in the ImageDecoder process. Then the object is serialized and sent through IPC, to finally be handed to skia for rendering. However, to make sure that we're not making all LibGfx's users dependent on Skia as well, we need to ensure the `Gfx::ColorSpace` object has no dependency on objects from Skia. To that end, the only member of the `ColorSpace` class is the opaque `ColorSpaceImpl` struct. Though, there is on issue with that design, the code in `DisplayListPlayer.cpp` needs access to the underlying `sk_sp<SkColorSpace>`. It is provided by a template function, that is only specialized for this type. Doing this work allows us to pass the following WPT tests: - https://wpt.live/css/css-color/tagged-images-001.html - https://wpt.live/css/css-color/tagged-images-003.html - https://wpt.live/css/css-color/tagged-images-004.html - https://wpt.live/css/css-color/untagged-images-001.html Other test cases can also be found here: - https://github.com/svgeesus/PNG-ICC-tests Note that SkColorSpace support quite a limited amount of color spaces, so color profiles like the ones in [1] or the v4 profiles in [2] are not supported yet. In fact, SkColorSpace only accepts skcms_ICCProfile with a linear conversion to XYZ D50. [1] https://www.color.org/browsertest.xalter [2] https://www.color.org/version4html.xalter
2024-12-02 20:55:43 -03:00
Gfx::ColorSpace color_profile;
ImageDecoder: Add streaming animation decode sessions Add IPC messages and server-side implementation for streaming animated image decode. Instead of decoding all frames upfront, only decode an initial batch and keep the decoder alive for on-demand frame requests. New IPC messages: - request_animation_frames: request decode of a batch of frames - stop_animation_decode: clean up a decode session - did_decode_animation_frames: deliver decoded frames to client - did_fail_animation_decode: report decode errors The existing did_decode_image message gains a session_id parameter (0 for single-shot decode, non-zero for streaming sessions).
2026-02-13 11:03:35 -03:00
// Non-null for streaming animated sessions:
RefPtr<Gfx::ImageDecoder> decoder;
Core::AnonymousBuffer encoded_data;
};
ImageDecoder: Decode images on ThreadPool Dispatch image decode work to ThreadPool workers instead of the old BackgroundAction helper. BackgroundAction funneled all jobs through one background thread, so image decodes were still serialized. The pool lets independent decode jobs run in parallel while completions are posted back to the origin event loop. Keep pending decode state as a small cancel flag. Make animated sessions ref-counted with a mutex so overlapping frame requests cannot race shared decoders once jobs run in parallel.
2026-06-04 19:47:10 -03:00
struct AnimationSession : public AtomicRefCounted<AnimationSession> {
ImageDecoder: Add streaming animation decode sessions Add IPC messages and server-side implementation for streaming animated image decode. Instead of decoding all frames upfront, only decode an initial batch and keep the decoder alive for on-demand frame requests. New IPC messages: - request_animation_frames: request decode of a batch of frames - stop_animation_decode: clean up a decode session - did_decode_animation_frames: deliver decoded frames to client - did_fail_animation_decode: report decode errors The existing did_decode_image message gains a session_id parameter (0 for single-shot decode, non-zero for streaming sessions).
2026-02-13 11:03:35 -03:00
Core::AnonymousBuffer encoded_data;
RefPtr<Gfx::ImageDecoder> decoder;
u32 frame_count { 0 };
ImageDecoder: Decode images on ThreadPool Dispatch image decode work to ThreadPool workers instead of the old BackgroundAction helper. BackgroundAction funneled all jobs through one background thread, so image decodes were still serialized. The pool lets independent decode jobs run in parallel while completions are posted back to the origin event loop. Keep pending decode state as a small cancel flag. Make animated sessions ref-counted with a mutex so overlapping frame requests cannot race shared decoders once jobs run in parallel.
2026-06-04 19:47:10 -03:00
Sync::Mutex decoder_mutex;
ImageDecoder: Schedule decode jobs on the LibThreading background thread This allows the ImageDecoder service to handle new IPC requests while decoding in parallel.
2024-04-23 21:58:52 -03:00
};
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 16:35:22 -03:00
private:
ImageDecoder: Decode images on ThreadPool Dispatch image decode work to ThreadPool workers instead of the old BackgroundAction helper. BackgroundAction funneled all jobs through one background thread, so image decodes were still serialized. The pool lets independent decode jobs run in parallel while completions are posted back to the origin event loop. Keep pending decode state as a small cancel flag. Make animated sessions ref-counted with a mutex so overlapping frame requests cannot race shared decoders once jobs run in parallel.
2026-06-04 19:47:10 -03:00
struct PendingJob : public AtomicRefCounted<PendingJob> {
void cancel() { m_canceled.store(true, AK::MemoryOrder::memory_order_relaxed); }
bool is_canceled() const { return m_canceled.load(AK::MemoryOrder::memory_order_relaxed); }
private:
Atomic<bool> m_canceled { false };
};
ImageDecoder: Add streaming animation decode sessions Add IPC messages and server-side implementation for streaming animated image decode. Instead of decoding all frames upfront, only decode an initial batch and keep the decoder alive for on-demand frame requests. New IPC messages: - request_animation_frames: request decode of a batch of frames - stop_animation_decode: clean up a decode session - did_decode_animation_frames: deliver decoded frames to client - did_fail_animation_decode: report decode errors The existing did_decode_image message gains a session_id parameter (0 for single-shot decode, non-zero for streaming sessions).
2026-02-13 11:03:35 -03:00
using FrameDecodeResult = Vector<Gfx::ImageFrameDescriptor>;
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 17:23:16 -03:00
Everywhere: Make TransportSocket non-movable Instead of wrapping all non-movable members of TransportSocket in OwnPtr to keep it movable, make TransportSocket itself non-movable and wrap it in OwnPtr.
2025-04-08 17:01:46 -03:00
explicit ConnectionFromClient(NonnullOwnPtr<IPC::Transport>);
Services: Fix visibility of Object-derivative constructors Derivatives of Core::Object should be constructed through ClassName::construct(), to avoid handling ref-counted objects with refcount zero. Fixing the visibility means that misuses like this are more difficult.
2021-10-31 19:38:04 -03:00
LibImageDecoderClient: Remove sync id fetch from async decode request
2026-02-21 17:48:14 -03:00
virtual void decode_image(Core::AnonymousBuffer, Optional<Gfx::IntSize> ideal_size, Optional<ByteString> mime_type, i64 request_id) override;
virtual void cancel_decoding(i64 request_id) override;
ImageDecoder: Add streaming animation decode sessions Add IPC messages and server-side implementation for streaming animated image decode. Instead of decoding all frames upfront, only decode an initial batch and keep the decoder alive for on-demand frame requests. New IPC messages: - request_animation_frames: request decode of a batch of frames - stop_animation_decode: clean up a decode session - did_decode_animation_frames: deliver decoded frames to client - did_fail_animation_decode: report decode errors The existing did_decode_image message gains a session_id parameter (0 for single-shot decode, non-zero for streaming sessions).
2026-02-13 11:03:35 -03:00
virtual void request_animation_frames(i64 session_id, u32 start_frame_index, u32 count) override;
virtual void stop_animation_decode(i64 session_id) override;
Everywhere: Transition ImageDecoder to be single-instance, owned by UI This is the same behavior as RequestServer, with the added benefit that we know how to gracefully reconnect ImageDecoder to all WebContent processes on restart.
2024-06-26 16:44:42 -03:00
virtual Messages::ImageDecoderServer::ConnectNewClientsResponse connect_new_clients(size_t count) override;
LibWebView+ImageDecoder+RequestServer+WebContent: Add init_transport
2025-01-03 13:19:46 -03:00
virtual Messages::ImageDecoderServer::InitTransportResponse init_transport(int peer_pid) override;
Everywhere: Transition ImageDecoder to be single-instance, owned by UI This is the same behavior as RequestServer, with the added benefit that we know how to gracefully reconnect ImageDecoder to all WebContent processes on restart.
2024-06-26 16:44:42 -03:00
LibIPC+LibWeb+LibWebView+Services: Add IPC::TransportHandle Add IPC::TransportHandle as an abstraction for passing IPC transports through .ipc messages. This replaces IPC::File at all sites where a transport (not a generic file) is being transferred between processes. TransportHandle provides from_transport(), clone_from_transport(), and create_transport() methods that encapsulate the fd-to-socket-to-transport conversion in one place. This is preparatory work for Mach port support on macOS -- when that lands, only TransportHandle's internals need to change while all .ipc definitions and call sites remain untouched.
2026-03-11 16:10:08 -03:00
ErrorOr<IPC::TransportHandle> connect_new_client();
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 17:23:16 -03:00
ImageDecoder: Decode images on ThreadPool Dispatch image decode work to ThreadPool workers instead of the old BackgroundAction helper. BackgroundAction funneled all jobs through one background thread, so image decodes were still serialized. The pool lets independent decode jobs run in parallel while completions are posted back to the origin event loop. Keep pending decode state as a small cancel flag. Make animated sessions ref-counted with a mutex so overlapping frame requests cannot race shared decoders once jobs run in parallel.
2026-06-04 19:47:10 -03:00
NonnullRefPtr<PendingJob> start_decode_image_job(i64 request_id, Core::AnonymousBuffer, Optional<Gfx::IntSize> ideal_size, Optional<ByteString> mime_type);
NonnullRefPtr<PendingJob> start_frame_decode_job(i64 session_id, NonnullRefPtr<AnimationSession>, u32 start_frame_index, u32 end_index);
ImageDecoder: Handle decoding of images in an asynchronous manner ImageDecoder now queues up image decoding requests and returns the images back to the caller later. ImageDecoderClient has a new promise-based API that allows callers to attach their own resolve/reject handlers to the responses from ImageDecoder.
2024-04-19 17:23:16 -03:00
ImageDecoder: Add streaming animation decode sessions Add IPC messages and server-side implementation for streaming animated image decode. Instead of decoding all frames upfront, only decode an initial batch and keep the decoder alive for on-demand frame requests. New IPC messages: - request_animation_frames: request decode of a batch of frames - stop_animation_decode: clean up a decode session - did_decode_animation_frames: deliver decoded frames to client - did_fail_animation_decode: report decode errors The existing did_decode_image message gains a session_id parameter (0 for single-shot decode, non-zero for streaming sessions).
2026-02-13 11:03:35 -03:00
i64 m_next_session_id { 1 };
ImageDecoder: Decode images on ThreadPool Dispatch image decode work to ThreadPool workers instead of the old BackgroundAction helper. BackgroundAction funneled all jobs through one background thread, so image decodes were still serialized. The pool lets independent decode jobs run in parallel while completions are posted back to the origin event loop. Keep pending decode state as a small cancel flag. Make animated sessions ref-counted with a mutex so overlapping frame requests cannot race shared decoders once jobs run in parallel.
2026-06-04 19:47:10 -03:00
HashMap<i64, NonnullRefPtr<PendingJob>> m_pending_jobs;
HashMap<i64, NonnullRefPtr<AnimationSession>> m_animation_sessions;
HashMap<i64, NonnullRefPtr<PendingJob>> m_pending_frame_jobs;
ImageDecoder: Add a new service for out-of-process image decoding :^) The new ImageDecoder service (available for members of "image" via /tmp/portal/image) allows you to decode images in a separate process. This will allow programs to confidently load untrusted images, since the bulk of the security concerns are sandboxed to a separate process. The only API right now is a synchronous IPC DecodeImage() call that takes a shbuf with encoded image data and returns a shared buffer and metadata for the decoded image. It also comes with a very simple library for interfacing with the ImageDecoder service: LibImageDecoderClient. The name is a bit of a mouthful but I guess we can rename it later if we think of something nicer to call it. There's obviously a bit of overhead to spawning a separate process for every image decode, so this is mostly only appropriate for untrusted images (e.g stuff downloaded from the web) and not necessary for trusted local images (e.g stuff in /res)
2020-06-22 16:35:22 -03:00
};
}
Reference in a new issue Copy permalink